I have some errors when I use mod_proxy_ajp or mod_prox_balancer under solicited server. I have this problem under apache 2.2.3 too.
My virtualhost configuration : ------------------------------ <VirtualHost ***.***.116:443> ServerName ***website*** VirtualDocumentRoot /data/webapps/***website*** # Options repartition de charge logiciel ProxyPass /balancer-manager ! ProxyPass / balancer://mycluster/ stickysession=JSESSIONID <Proxy balancer://mycluster> BalancerMember ajp://server.*******:9514 min=0 max=200 smax=100 ttl=10 route=**** loadfactor=25 BalancerMember ajp://server.*******:9514 min=0 max=200 smax=100 ttl=10 route=**** loadfactor=25 BalancerMember ajp://server.*******:9514 min=0 max=200 smax=100 ttl=10 route=**** loadfactor=50 </Proxy> # Options pour le https SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP SSLCertificateFile /etc/certificats/***website***.crt SSLCertificateKeyFile /etc/certificats/***website***.key SSLCertificateChainFile /etc/certificats/chainage.txt SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" # Ajout car sinon ne loggue pas ce virtualhost CustomLog logs/access_log comonvhost ErrorLog logs/error_log </VirtualHost>
Created attachment 19670 [details] extra/httpd-mpm.conf configuration
Created attachment 19671 [details] Error_log extract
I think the socket does not get closed properly.
When I have errors, if I launch netstat command, the result is : [root@**** httpd_80]$ netstat -tn | egrep "^tcp.*:9514" | tr -s " " | cut -f6 -d " " | sort | uniq -c 30 CLOSE_WAIT 177 ESTABLISHED 1 FIN_WAIT2 [root@**** httpd_80]$ netstat -tn | egrep "^tcp.*:9514" | tr -s " " | cut -f6 -d " " | sort | uniq -c 30 CLOSE_WAIT 174 ESTABLISHED 1 FIN_WAIT2 [root@**** httpd_80]$ netstat -tn | egrep "^tcp.*:9514" | tr -s " " | cut -f6 -d " " | sort | uniq -c 30 CLOSE_WAIT 176 ESTABLISHED 1 TIME_WAIT
Thanks for your detailed analysis. Although this is not obvious from the error messages they simply state that the client has closed the connection before all data from the backend has been transfered to the client (usually because someone pressed the stop button in the browser). So no need to worry about this. Regarding the connections in CLOSE_WAIT state: Is any of the balancer members running on the same box as your webserver?
Thanks for your answer, Ruediger. As you ask, there is one balancer member running on the same box as the webserver.
(In reply to comment #7) > Thanks for your answer, Ruediger. As you ask, there is one balancer member > running on the same box as the webserver. So I currently assume that the sockets in CLOSE_WAIT state belong to the balancer member on your box. If httpd is not able to sent the full contents to the client it closes the connection to the backend to 1. Avoid any hickups with stuck content when reusing this connection. 2. To give the backend a chance to discover that the content requested will not be consumed and thus possible expensive operations to generate the remaining part of the content can be stopped. So I assume that the application in your balancer has not closed its part of the socket after httpd has closed its side of the socket. Can you please cross check?
How do you sugest me to cross check ?
netstat -apn executed as root should be your friend. It shows which process owns the respective socket.
Created attachment 19701 [details] Result of netstat command Result of this command : netstat -apn > /tmp/toto && netstat -tn | egrep "^tcp.*:9514" | tr -s " " | cut -f6 -d " " | sort | uniq -c >> /tmp/toto
Ok, as the sockets being in CLOSE_WAIT state belong to httpd processes, my theory seems to be wrong :-). Another approach: I do not know the application server to which you connect via ajp. Possibly it has a timeout for these ajp connections and closes them after a certain idle period or it closes them for any other reason. The socket will remain in CLOSE_WAIT status on httpd side until the connection is chosen again from the connection pool by the specific worker. httpd will notice that the connection has been closed by the other end, will close its end of the connection and create a new socket for a new connection.
Somehow got assigned as a log4j bug.
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.