apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: apr_reslist semantics
Date Mon, 12 May 2008 20:53:03 GMT


On 05/12/2008 09:22 PM, Nick Kew wrote:
> In https://issues.apache.org/bugzilla/show_bug.cgi?id=42841 ,
> Tom points out an issue that gives problems with MySQL
> (and possibly other DBD drivers) and suggests that a change
> to apr_reslist semantics would fix it.  Tom also attaches
> a patch implementing his proposed change.
> 
> Prompted by a recent post to dev@httpd concerning an old
> chesnut PR#37770, I see we have the same usage of reslist
> in managing proxy backend connections.  Except that the
> mod_proxy documentation hints at precisely the behaviour
> Tom suggests:
>   "ttl - ..... Apache will close all connections that
>    has not been used inside that time period."
> 
> Grammar aside, that suggests incorrectly that ttl can be
> used to prevent the server re-using a connection that's
> been idle for more than a specified period.  If that
> were in fact how it worked, it could fix both bugs.
> 
> Of course we can't just hack apr_reslist willy-nilly.
> But perhaps it's time to introduce an additional API, 
> or even an environment variable, that will select
> the "maximum idle lifetime of a resource" semantics
> of TTL.

It sounds reasonable to adjust the behaviour of apr_reslist,
but as said by you we can't do this for the default behaviour and
an environment variable doesn't sound really sexy to me either. What about
either an apr_reslist_create_ex function that allows to set this TTL
parameter with the respective meaning described above and let
apr_reslist_create set the value to 0 which mean indefinitely?
Or we create a new function similar to apr_reslist_timeout_set that sets
this value (I like the second proposal more).
Of course this would need to happen before the release of 1.3.0 if we want
to bring this into 1.3.x.

Regards

RĂ¼diger



Mime
View raw message