Since we have upgrade lot of our frontend server in version 2.2.13 we have an issue with mod_proxy_balancer or mod_proxy_ajp. In our logs we can see this message : httpd[17077]: [error] proxy: dialog to 129.***.***.***:9554 (jent2.****.fr) failed httpd[29288]: [error] proxy: dialog to 129.***.***.***:9554 (jent5.****.fr) failed httpd[10466]: [error] proxy: dialog to 129.***.***.***:9554 (jent5.****.fr) failed httpd[28229]: [error] proxy: dialog to 129.***.***.***:9554 (jent2.****.fr) failed httpd[29287]: [error] proxy: dialog to 129.***.***.***:9554 (jent1.****.fr) failed httpd[17539]: [error] proxy: dialog to 129.***.***.***:9554 (jent3.****.fr) failed httpd[28229]: [error] proxy: dialog to 129.***.***.***:9554 (jent1.****.fr) failed All five backend server are under Tomcat 5.5.27. Apache configuration : <VirtualHost 129.***.***.***:80> ServerName ent.******.fr VirtualDocumentRoot /dev/null # Balancing ProxyPass /balancer-manager ! ProxyPass / balancer://mycluster/ stickysession=JSESSIONID <Proxy balancer://mycluster> BalancerMember ajp://129.***.***.***:9554 min=0 max=100 smax=50 ttl=10 route=ent1 timeout=60 loadfactor=100 BalancerMember ajp://129.***.***.***:9554 min=0 max=100 smax=50 ttl=10 route=ent2 timeout=60 loadfactor=100 BalancerMember ajp://129.***.***.***:9554 min=0 max=100 smax=50 ttl=10 route=ent3 timeout=60 loadfactor=100 BalancerMember ajp://129.***.***.***:9554 min=0 max=100 smax=50 ttl=10 route=ent4 timeout=60 loadfactor=100 BalancerMember ajp://129.***.***.***:9554 min=0 max=100 smax=50 ttl=10 route=ent5 timeout=60 loadfactor=100 </Proxy> </VirtualHost> To fix this issue, we just come back to the 2.2.11 version ...
Please set the LogLevel to debug for further diagnostics.
Out of curiosity, if you revert this patch and recompile mod_proxy_ajp; http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/proxy/mod_proxy_ajp.c?r1=768507&r2=768506&pathrev=768507 do the problems go away?
waiting for answers to comments
Same problem (Apache 2.2.13 + Tomcat 5.5.26 with uPortal webapp) [Fri Sep 25 13:15:29 2009] [debug] ajp_header.c(687): ajp_read_header: ajp_ilink_received 04 [Fri Sep 25 13:15:29 2009] [debug] ajp_header.c(697): ajp_parse_type: got 04 [Fri Sep 25 13:15:29 2009] [debug] ajp_header.c(516): ajp_unmarshal_response: status = 200 [Fri Sep 25 13:15:29 2009] [debug] ajp_header.c(537): ajp_unmarshal_response: Number of headers is = 5 [Fri Sep 25 13:15:29 2009] [debug] ajp_header.c(599): ajp_unmarshal_response: Header[0] [uPortal-version] = [uPortal_rel-2-6-1] [Fri Sep 25 13:15:29 2009] [debug] ajp_header.c(599): ajp_unmarshal_response: Header[1] [pragma] = [no-cache] [Fri Sep 25 13:15:29 2009] [debug] ajp_header.c(599): ajp_unmarshal_response: Header[2] [Cache-Control] = [no-cache, max-age=0, must-revalidate] [Fri Sep 25 13:15:29 2009] [debug] ajp_header.c(599): ajp_unmarshal_response: Header[3] [Expires] = [Thu, 01 Jan 1970 00:00:00 GMT] [Fri Sep 25 13:15:29 2009] [debug] ajp_header.c(599): ajp_unmarshal_response: Header[4] [Content-Type] = [text/html;charset=UTF-8] [Fri Sep 25 13:15:29 2009] [debug] ajp_header.c(609): ajp_unmarshal_response: ap_set_content_type done [Fri Sep 25 13:15:29 2009] [debug] ajp_header.c(687): ajp_read_header: ajp_ilink_received 04 [Fri Sep 25 13:15:29 2009] [debug] ajp_header.c(697): ajp_parse_type: got 04 [Fri Sep 25 13:15:29 2009] [debug] mod_proxy_ajp.c(424): proxy: Backend sent headers twice. [Fri Sep 25 13:15:29 2009] [debug] mod_proxy_ajp.c(540): proxy: Processing of request failed backend: 1, output: 0 [Fri Sep 25 13:15:29 2009] [error] proxy: dialog to 127.0.0.1:8009 (localhost) failed
There can be several reasons, why the backend sends the headers duplicate. It could be a webapp problem, but there's also a Tomcat bug, that has been fixed recently: https://issues.apache.org/bugzilla/show_bug.cgi?id=46770 The probem starts in 5.5.26 and is fixed in 5.5.28. So you can either apply the patch http://svn.apache.org/viewvc?view=rev&revision=755236 or update your Tomcat to 5.5.28. If this doesn't help, then it's likely something in your webapp. The other option is removing the protocol hardening done by the httpd patch that Bill Wrowe mentioned in Comment #2. Could both of you, "S" and "ML" please check, whether the problem goes away when using TC 5.5.28?
No more errors for me after upgrading to Tomcat 5.5.28. Thanks.
@Will Rowe : sorry but I can't revert the patch now. Our servers are in production and users (30 000 connexions per day) can't tolerate another issues. @ML : I think we have exactly the same issue, because we use uPortal webapps too ... :-) I think I upgrade Tomcat servers in 5.5.28 version soon ...
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.