For sure it's a firewall problem... the FW will close the connection but Apache won't know about it. You can also see this happen when using mod_jk and AJP.
Other than getting a non-brain-dead FW, totally disabling the connection pool is the work around. On Jan 29, 2013, at 11:25 AM, sebastien.allam...@orange.com wrote: > > > When looking in detail on requests, we can see that mod_proxy don’t close > properly the request (it waits for the next request to send FIN-HACK to the > backend). > > mod_proxy doesn't normally close the backend connection immediately after > using it. Instead, the connection will be closed when processing a > subsequent request and it is then determined that the connection can't be > reused. This behavior is expected and rarely (if ever) the *root* cause of > operational problems, though there are some circumstances where turning off > backend connection reuse is appropriate. > > Is the backend server returning 503s because a lot of connections from the > proxy are in keep-alive state? If so, maybe you should lower keepalive > timeouts for the backend connection > > The keepAlive between our RP and the backend is not activated. > It’s not the backend that respond the 503 but the RP directly. > There is a lot of connection in CLOSE_WAIT state on the server. > > We have decrease by 10 from 3% of requests to 0,3% of requests be reducing > the timeout on the firewall between our RP and the backend from 60 to 5 > secondes. > I’m not sure how to solve the problem, that still happen on heavy load. > > > > > > <image002.jpg> > > I’ve found that a similar issue have already been reported : > https://issues.apache.org/bugzilla/show_bug.cgi?id=50807 > > Is there any correction on the mod_proxy regarding this problem, would it > appears again using apache 2.4 ? > > Thanks in advance for replies. > > > Sébastien > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages > that have been modified, changed or falsified. > Thank you. > > > > -- > Born in Roswell... married an alien... > http://emptyhammock.com/ > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages > that have been modified, changed or falsified. > Thank you. >
