Bug 39692 - mod_proxy_balancer doesn't retry a failed request
Summary: mod_proxy_balancer doesn't retry a failed request
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy_balancer (show other bugs)
Version: 2.2.2
Hardware: Other other
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate
Depends on:
Reported: 2006-05-31 14:48 UTC by R Ayres
Modified: 2018-11-07 21:09 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description R Ayres 2006-05-31 14:48:28 UTC
mod_proxy_balancer doesn't appear to retry requests that fail before completing.

For example with the setup, two Tomcat servers connected to an Apache server
balanced with mod_proxy_balancer.  If I manually kill one of the Tomcat servers
during a long request, the request continues until timeout (and eventual 503
Service Unavailable result).  Shouldn't mod_proxy_balancer really timeout and/or
read the response code and then retry the request (thus pushing it onto a
failover server)?
Comment 1 Ruediger Pluem 2006-05-31 19:47:25 UTC
It may be a good idea to have this somewhat configurable like this is possible
with mod_jk's recovery_options
(http://tomcat.apache.org/connectors-doc/config/workers.html), but as a default
I would prefer leaving it as it is.

1. The retry behaviour should be only allowed for requests that are idempotent
according to RFC2616 9.1.2, see also 8.1.4 of RFC2616. 
2. Even methods marked as idempotent as GET are not always idempotent, e.g. if
they have a query string.
3. You cannot resend the request to a different Tomcat once you have sent out
data to the client. This would corrupt the response.
Comment 2 R Ayres 2006-06-01 15:03:47 UTC
After some careful thought to your reply, I think you are indeed correct in how
mod_proxy_balancer should, by default, respond with a failure mid-request.  It
is not the responsibility of the proxy to know if a request is idempotent or not
and so cannot retry assuming that it is.

It would be nice to see this configurable as per mod_jk's recovery_options
however as it is possible to develop web requests so they are idempotent and an
automated proxy retry (even if corrupted due to a part-written response) could
be useful.
Comment 3 William A. Rowe Jr. 2018-11-07 21:09:39 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.