Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of DRuggeri@primary.net designates
 216.87.38.201 as permitted sender)
Message-ID: <558C9FB0.2030902@primary.net>
Date: Thu, 25 Jun 2015 19:41:20 -0500
From: Daniel Ruggeri <DRuggeri@primary.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Proxy balancer providers and aging
References: <EC9DA55A-B29E-4965-A8E3-C84170F7A6AC@jaguNET.com>
In-Reply-To: <EC9DA55A-B29E-4965-A8E3-C84170F7A6AC@jaguNET.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

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