On 07/04/2010 04:38 PM, Daniel Ruggeri wrote: > On 7/1/2010 1:46 AM, jean-frederic clere wrote: >> On 07/01/2010 03:14 AM, Daniel Ruggeri wrote: >> >>> On 6/30/2010 7:34 AM, jean-frederic clere wrote: >>> >>>> On 06/30/2010 04:17 AM, William A. Rowe Jr. wrote: >>>> >>>> >>>>> Yet again, in class another student pointed out that the >>>>> Enabled/Disabled >>>>> choice in mod_proxy_balancer totally ignores the concept of quiescing, >>>>> where we are taking a server offline, but continuing to serve those >>>>> requests targeted by session to that server. Once the number of >>>>> sessions >>>>> settles on something quite low, the user then takes that server >>>>> offline >>>>> entirely and the remaining users are subjected to 'expired session' >>>>> results. >>>>> >>>>> A boolean Enabled/Disabled flag doesn't address this need. >>>>> >>>>> Does anyone feel like working on this feature, since those I had >>>>> previously approached didn't have all that much interest, or got >>>>> busy with other things? >>>>> >>>>> >>>>> >>>>> >>>> There are several things that requires improvements: >>>> 1 - The default load balancing logic doesn't work well when you restart >>>> a back-end node. >>>> >>>> ... >>>> >>>> Cheers >>>> >>>> Jean-Frederic >>>> >>>> >>>> >>> Jean-Frederic; >>> Can you elaborate more on point 1? I have had issues where a back >>> end >>> application was not ready during a restart and throws a 503 to Apache. >>> Since this is a perfectly valid response to the proxied request, Apache >>> happily sends it along to the user. I wrote a bug (48939) and submitted >>> a patch that creates a configuration directive to help mitigate this >>> issue which is the most significant issue I have come across during a >>> simple back end restart. The patch is currently proposed in STATUS, but >>> has not received votes to go forward (or stay in STATUS). >>> >> That is something different the algorithm used doesn't work correctly >> when you have long lasting sessions and the load for the past is not >> forgotten... Basically to much load is going to the returning back-end. >> >> Your patch is just a work-around to the problem that httpd doesn't know >> that the back-end shouldn't be used at that time. >> >> Cheers >> >> Jean-Frederic >> >> > Jean-Frederic; > That's a very good point and a qualm I have had with httpd for a > while myself. As it is, the current balancer setup relies on live > traffic to figure out if the backend is OK. Some hardware load balancers > have the ability to "ping" backends with anything from simple TCP, HTTP > HEAD or even SSL handshakes. Perhaps adding something like that to HTTPD > would be the trick? The logistics of configuring such a thing might be a > little complicated in httpd.conf... perhaps another argument that can be > passed to ProxyPass? > Configured like so? > ProxyPass (or ProxySet or BalancerMember) /context > http://someBackend:1234/context httpProbe="HEAD /context/helloWorld.do" > probeInterval=15 > > > Of course, this is all conceptual - what do you think of the idea?
That is something like the worker.maintain directive of mod_jk but with the request to do. Something like: maintain=time|method|[URI] maintain=60|CPING| maintain=60|HEAD|/context/helloWorld.do In the case we make a request that requires the application to be able to process it as a probe request. > While > this is a feature that would be *incredibly* useful, I don't think I > have the required expertise with httpd's code to execute it. Well that is not so easy: it requires a thread (a thread per worker) and to update the status of the worker out of a real request which is requires some care. Cheers Jean-Frederic
