Proxy balancer providers and aging

[Jim Jagielski <ji...@jaguNET.com>]

All LBmethods have an "age" function which is designed to appropriately
"age" the data so that things even out after awhile. Of course, right
now, none actually *uses* that.

But I think the reason is because there is no real good way,
currently, in mod_proxy to do that...

Well, in the LBmethod I was hacking away on, it really DOES need
its age function, and currently it's doing so via mod_watchdog.
But the more I think of it, ideally, mod_proxy *itself* should
create the watchdog thread and just handle the age itself, rather
than having a LBmethod provider having to be responsible for
creating that (it also kind of destroys the abstraction that pure
providers should have, imo)...

Anyway... anyone opposed to me adding this to mod_proxy in
trunk with hope towards it backporting to 2.4? It does mean
that mod_proxy will now have a dependency on mod_watchdog.

Re: Proxy balancer providers and aging

[Jim Jagielski <ji...@jaguNET.com>]

> On Jun 25, 2015, at 8:41 PM, Daniel Ruggeri <DR...@primary.net> wrote:
> 
> On 6/24/2015 3:12 PM, Jim Jagielski wrote:
>> All LBmethods have an "age" function which is designed to appropriately
>> "age" the data so that things even out after awhile. Of course, right
>> now, none actually *uses* that.
>> 
> 
> I had never realized this function exists... what triggers it? ... or
> are you saying that today nothing triggers it because of the next sentence?

Yep... we have the function as part of the provider structure, but
we never use it or call it. 
> 
>> But I think the reason is because there is no real good way,
>> currently, in mod_proxy to do that...
>> 
>> Well, in the LBmethod I was hacking away on, it really DOES need
>> its age function, and currently it's doing so via mod_watchdog.
>> But the more I think of it, ideally, mod_proxy *itself* should
>> create the watchdog thread and just handle the age itself, rather
>> than having a LBmethod provider having to be responsible for
>> creating that (it also kind of destroys the abstraction that pure
>> providers should have, imo)...
>> 
> 
> Yup - if there is some sort of contract between mod_proxy such that each
> balancer ought to be able to "age" its data, mod_proxy should provide
> the facilities to call that age function on some interval.

Agreed.

> However,
> looking at the age function signature in the existing balancers, I'm
> seeing a conspicuous lack of a time delta since the last call to age().
> It seems to me that if mod_proxy is responsible for the 'tick' it should
> also be responsible for providing a time delta so the lbmethod can age
> the data proportionally to the time since last tick.

I have been thinking about this and it seems to me that the
simplest would be to have mod_proxy guarantee that age is
called every hour (or whatever constant we all agree with).

> 
> (or, maybe I'm missing it altogether and the module should be managing
> this itself which kinda puts us back to the beginning of which module
> should be responsible for this stuff)
> 
> 
>> Anyway... anyone opposed to me adding this to mod_proxy in
>> trunk with hope towards it backporting to 2.4? It does mean
>> that mod_proxy will now have a dependency on mod_watchdog.
> 
> I'm conflicted. This is useful functionality but would break existing
> configurations using 2.4 in an unexpected way. I remember dealing with
> lots of questions about "why is this slotmem thing needed all of a
> sudden" when moving from 2.2 to 2.4.

yeah, I see that point.

Re: Proxy balancer providers and aging

[Daniel Ruggeri <DR...@primary.net>]

On 6/24/2015 3:12 PM, Jim Jagielski wrote:
> All LBmethods have an "age" function which is designed to appropriately
> "age" the data so that things even out after awhile. Of course, right
> now, none actually *uses* that.
> 

I had never realized this function exists... what triggers it? ... or
are you saying that today nothing triggers it because of the next sentence?

> But I think the reason is because there is no real good way,
> currently, in mod_proxy to do that...
> 
> Well, in the LBmethod I was hacking away on, it really DOES need
> its age function, and currently it's doing so via mod_watchdog.
> But the more I think of it, ideally, mod_proxy *itself* should
> create the watchdog thread and just handle the age itself, rather
> than having a LBmethod provider having to be responsible for
> creating that (it also kind of destroys the abstraction that pure
> providers should have, imo)...
> 

Yup - if there is some sort of contract between mod_proxy such that each
balancer ought to be able to "age" its data, mod_proxy should provide
the facilities to call that age function on some interval. However,
looking at the age function signature in the existing balancers, I'm
seeing a conspicuous lack of a time delta since the last call to age().
It seems to me that if mod_proxy is responsible for the 'tick' it should
also be responsible for providing a time delta so the lbmethod can age
the data proportionally to the time since last tick.

(or, maybe I'm missing it altogether and the module should be managing
this itself which kinda puts us back to the beginning of which module
should be responsible for this stuff)


> Anyway... anyone opposed to me adding this to mod_proxy in
> trunk with hope towards it backporting to 2.4? It does mean
> that mod_proxy will now have a dependency on mod_watchdog.

I'm conflicted. This is useful functionality but would break existing
configurations using 2.4 in an unexpected way. I remember dealing with
lots of questions about "why is this slotmem thing needed all of a
sudden" when moving from 2.2 to 2.4.

I think that if I were to be forced to work through the cognitive
dissonance I'd be +1 for adding this to trunk but -1 for 2.4 unless we
can find a way to avoid the dependency unless the lbmethod really needs
it (I don't see how, but please do enlighten me if this is possible).

-- 
Daniel Ruggeri