> On Jun 25, 2015, at 8:41 PM, Daniel Ruggeri <[email protected]> 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.
