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=43958>. 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=43958 Summary: mod_proxy_balancer not balancing correct in combination with MAX=1 Product: Apache httpd-2 Version: 2.2.6 Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: mod_proxy_balancer AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] Im having a setup on Gentoo, Apache 2.2.6 with a setup that relies on mod_proxy_balancer: Apache is the proxy and proxies request to 3 workers (in fact, Mongrel which is a basic HTTP server server Ruby code). Rewriting rules are in places and on normal use no issues, so I guess the setup is correct. In my testing enviroment (i.e. I have full control over de requests sent to the setup), I experience the following: Setup A: <Proxy balancer://ips.dev.test_setup.com.mongrel_cluster> BalancerMember http://localhost:8010 BalancerMember http://localhost:8011 BalancerMember http://localhost:8012 </Proxy> I request an action that takes a long time to execute (10 minutes). This is for testing purposes. Than I fire subsequents requests with normal execution time (< 1 second). The results are: - worker 8010 gets the first long request and starts handling this - worker 8011 and 8012 get the next two requests - request 4 is proxied to 8010 where it has to wait for the long request to finish before it gets served. This is expected behaviour. Next, Ive changed the configuration to Setup B: <Proxy balancer://ips.dev.test_setup.com.mongrel_cluster> BalancerMember http://localhost:8010 max=1 BalancerMember http://localhost:8011 max=1 BalancerMember http://localhost:8012 max=1 </Proxy> Im repeating the experiment. The results are the same as in setup A. In my opinion this is unexpected behaviour: 8010 gets the first long request and while serving this, it should not get any subsequent request until the initial request has been fully served. IMHO this is the meaning of parameter MAX=1. The other workers should handle the subsequent requests. (I fire the request by hand, with a large enough interval to get a free worker available). More-over if I look in the balancer-manager, all workers have state Ok. I would expect to see a state Busy (or something like that for 8010). This seems related to bug #42668. Effectively, Im looking for a solution that one bad performance thread does not hurt the overall response -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
