httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfcl...@gmail.com>
Subject Re: Missing proxy_balancer feature
Date Mon, 05 Jul 2010 07:01:12 GMT
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

Mime
View raw message