Bug 41771

Summary: Erro with mod_proxy_ajp or mod_prox_balancer
Product: Apache httpd-2 Reporter: Seb <sebastien.bilbeau>
Component: mod_proxy_balancerAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: RESOLVED LATER    
Severity: normal Keywords: MassUpdate
Priority: P2    
Version: 2.0-HEAD   
Target Milestone: ---   
Hardware: Other   
OS: Linux   
Attachments: extra/httpd-mpm.conf configuration
Error_log extract
Result of netstat command

Description Seb 2007-03-06 02:12:41 UTC
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.
Comment 1 Seb 2007-03-06 02:13:33 UTC
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>
Comment 2 Seb 2007-03-06 02:15:07 UTC
Created attachment 19670 [details]
extra/httpd-mpm.conf configuration
Comment 3 Seb 2007-03-06 02:16:29 UTC
Created attachment 19671 [details]
Error_log extract
Comment 4 Seb 2007-03-06 02:23:33 UTC
I think the socket does not get closed properly.
Comment 5 Seb 2007-03-06 02:30:32 UTC
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
Comment 6 Ruediger Pluem 2007-03-06 13:07:52 UTC
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?
Comment 7 Seb 2007-03-07 00:28:09 UTC
Thanks for your answer, Ruediger. As you ask, there is one balancer member
running on the same box as the webserver.
Comment 8 Ruediger Pluem 2007-03-07 12:20:17 UTC
(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?
Comment 9 Seb 2007-03-12 02:10:25 UTC
How do you sugest me to cross check ?
Comment 10 Ruediger Pluem 2007-03-12 14:53:28 UTC
netstat -apn executed as root should be your friend. It shows which process owns
the respective socket.
Comment 11 Seb 2007-03-13 02:29:24 UTC
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
Comment 12 Ruediger Pluem 2007-03-13 13:52:44 UTC
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.
Comment 13 Curt Arnold 2007-08-21 15:30:41 UTC
Somehow got assigned as a log4j bug.
Comment 14 William A. Rowe Jr. 2018-11-07 21:09:17 UTC
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.