> -----Original Message----- > From: Mark Thomas <ma...@apache.org> > Sent: Monday, March 6, 2023 10:34 AM > To: users@tomcat.apache.org > Subject: Re: health check return 404 after upgrade from 70 to tomcat 9.0.71 > > On 25/02/2023 17:57, Mark Thomas wrote: > > > > > > On 25/02/2023 15:47, Rui wrote: > >> Hi > >> recently upgraded tomcat to 9.0.71 from 9.0.70 but saw 404 in our EKS > >> cluster(with istio installed) > >> > >> Received [GET /actuator HTTP/1.1 > >> Host: xxxxx:8079 > >> User-Agent: kube-probe/1.23+ > >> Accept: */* > >> Connection: close > >> Accept-Encoding: gzip > >> ] > >> Incoming request /health with originalRemoteAddr xxxx > >> > >> in 9.0.70 I can see the below following message but not in 9.0.71 > >> o.a.c.authenticator.AuthenticatorBase : Security checking request > >> GET /health > >> > >> seems the processing has stopped somewhere and the pod health check > >> didn't pass. > >> > >> I also noticed there was also a 404 issue but don't know if it is > >> relevant. > >> https://urldefense.com/v3/__https://lists.apache.org/thread/gr814rmrl > >> bk9rrqxqjrh4p3x0bfvv1g9__;!!F9svGWnIaVPGSwU!uiVBZpR54vzNpwI- > 1lyRTgM4j > >> KczN4Bobrx34KVhfSRZo-W3EsxLU7epxoIiW_- > gA2CtJmE_dFUEWwJPZkCMDg$ > >> > >> I have tested it locally with curl or jmeter, but can't reproduce the > >> problem. > >> > >> but when I step by step debug the spring app, I found the > >> undecodedURI type is T_STR in CoyoteAdapter.java(in 70 it supposed to > >> be T_BYTES), then decodedURI is uninitialized and the uri can't find > >> the mapping in internalMap of Mapper.java, which will cause 404(guess > >> it thinks the uri is malformed) > >> > >> MessageBytes decodedURI = req.decodedURI(); > >> > >> if (undecodedURI.getType() == MessageBytes.T_BYTES) { > >> // Copy the raw URI to the decodedURI > >> decodedURI.duplicate(undecodedURI); > >> > >> > >> 404 example: (when I debug step by step to check unndecodedURI) > >> > >> curl > >> > https://urldefense.com/v3/__http://localhost:8080/actuator__;!!F9svGW > >> nIaVPGSwU!uiVBZpR54vzNpwI-1lyRTgM4jKczN4Bobrx34KVhfSRZo- > W3EsxLU7epxoI > >> iW_-gA2CtJmE_dFUEWwKRB2lDBg$ > >> > >> <!doctype html><html lang="en"><head><title>HTTP Status 404 – Not > >> Found</title><style type="text/css">body > >> {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b > >> {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 > >> {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a > >> {color:black;} .line > >> {height:1px;background- > color:#525D76;border:none;}</style></head><bod > >> y><h1>HTTP Status 404 – Not Found</h1></body></html>% > >> > >> > >> However, it runs well without breakpoint! I am quite confused...my > >> intellij has problem? > >> but anyway, summary: > >> 9.0.69 and 70 are good in the AWS/EKS(kubernetes) cluster with > >> istio > >> 9.0.71 and 72 return 404 when health check by the EKS cluster. > > > > Looks like an instance of: > > https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cg > > i?id=66488__;!!F9svGWnIaVPGSwU!uiVBZpR54vzNpwI- > 1lyRTgM4jKczN4Bobrx34KV > > hfSRZo-W3EsxLU7epxoIiW_-gA2CtJmE_dFUEWwJcG2lXgg$ > > If not that then maybe > > https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cgi? > id=66512__;!!F9svGWnIaVPGSwU!uiVBZpR54vzNpwI- > 1lyRTgM4jKczN4Bobrx34KVhfSRZo-W3EsxLU7epxoIiW_- > gA2CtJmE_dFUEWwIhYU5xdQ$ > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
I believe we may have figured out what was causing the issue, but not why it was causing it. In the mod-proxy-http configuration for the balancer, we had been using the fully qualified host name in the balancer url. When we switched to IP address, things got tremendously faster to the point we aren't seeing the health check fail any longer. What is perplexing is why removing a simple DNS lookup by going from host name to IP address had such a dramatic affect. Is this something that adding ProxyHost and ProxyPort to the connector would possibly cure? We have not tried that currently. Thanks, Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
