|Summary:||proxy balancer: timeout or partial failure of backend worker does not result in error state (with patch)|
|Component:||mod_proxy_balancer||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
|Attachments:||A patch to provide failonbadgateway setting and functionality to the mod_proxy_balancer.|
Description bpkroth 2013-02-01 15:47:24 UTC
Created attachment 29914 [details] A patch to provide failonbadgateway setting and functionality to the mod_proxy_balancer. Hello, We have a setup for a semi-busy site using mod_proxy_balancer together with sticky sessions and keepalives to map clients to various backends. In one odd case, one backend would accept connections, but some local IO was broken (of course in the middle of the night), so it would continuously timeout until someone kicked it. The timeout is setup ridiculously high for edge case application reasons, so that wasn't the issue. I was suprised to learn that the balancer did not mark that node as in error state so that it backed off of it. Basically it was the partial failure, but not complete failure that was the problem. Had there been a complete failure, the connection checks would have marked the node in error state, and had the node returned a status line (or really anything) the failonstatus configuration could have possibly caught it. Instead, since we were using byrequests at the time, the node handled fewer and fewer requests and was selected more and more over time to service new requests. Instead, I propose the following patch. It provides a "failonbadgateway" option that will mark a node as in error state if the handler returns a HTTP_BAD_GATEWAY response (in looking through the various modules this seems like a reasonable way to consolidate the case of timeouts as well as other backend worker protocol violations across several modules, and not just the mod_proxy_http one). Please let me know if you have any comments or questions. Thanks, Brian
Comment 1 Christophe JAILLET 2013-02-01 16:57:56 UTC
Hi, r1438130 must be wrong. It seems completely unrelated. Can you update it please ?
Comment 2 bpkroth 2013-02-01 19:27:57 UTC
Yeah, that was just the place my local repo was at when I did the svn diff. It's not related at all. Brian
Comment 3 William A. Rowe Jr. 2018-11-07 21:09:23 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.