httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 38962] - retry timeout not honored when configured in sticky mode
Date Thu, 31 May 2007 03:42:53 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38962>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38962





------- Additional Comments From Dale_Ogilvie@trimble.com  2007-05-30 20:42 -------
Looks like I'm seeing this bugs as well.

I am running Apache 2.2.3 on RedHat EL 5. I am trying to use Apache to load
balance between two local instances of tomcat in order to utilize the vast
quantities of RAM on our production server.

My httpd setup looks like this:

<Proxy balancer://tomcat>
    BalancerMember ajp://localhost:8009 min=10 max=100 route=tomcat1
loadfactor=1 retry=120
    BalancerMember ajp://localhost:8010 min=10 max=100 route=tomcat2
loadfactor=1 retry=120 </Proxy>

<Location /balancer-manager>
    SetHandler balancer-manager
    Order deny,allow
    Deny from all
    Allow from .trimblecorp.net
</Location>

ProxyPass /dscgi/ds.py/ balancer://tomcat/docushare/dsweb/
stickysession=JSESSIONID nofailover=On ProxyPass /docushare
balancer://tomcat/docushare stickysession=JSESSIONID nofailover=On ProxyPass
/docushare/ balancer://tomcat/docushare/ stickysession=JSESSIONID nofailover=On

The problem is that if one of the workers gets into error status, any client
with a JSESSIONID referencing that route is never able to receive a reply,
Apache *always* responds with a 503 – Temporarily unavailable, *until* another
request is successful. I expected with "retry=120" that after 120 seconds the
client would be able to use the errored out worker, but this is *not* the case.

Test case:

1. Start tomcats
2. Access /docushare, this succeeds and returns a JSESSIONID cookie referencing
the member e.g. JSESSIONID=BC90C156669FDF0194657FF27EC3AF99.tomcat2
3. Stop tomcats to simulate a backend failure 
4. Access /docushare again in the same browser session, this fails with a 503
error (as expected). Balance-manager shows tomcat1 is OK, and tomcat2 is Err
Error_log shows: All workers are in error state for route (tomcat2) 
5. Start tomcats again 
6. Wait for 120+ seconds to allow retry=120 to take effect
7. Access /docushare *using the session with the tomcat2 cookie*, expect
success, get 503 error. I can repeat this step ad nauseam without ever getting a
successful response.
Error_log shows: All workers are in error state for route (tomcat2) 
8. To resolve the issue, delete the JSESSIONID cookie from the client or open up
a new browser and access /docushare. Either of these seem to solve the problem
for the "cookied" browser session.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message