You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Nick Kew <ni...@webthing.com> on 2008/05/12 21:22:09 UTC
apr_reslist semantics
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.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: apr_reslist semantics
Posted by Henry Jen <he...@ztune.net>.
On Fri, May 23, 2008 at 12:28 PM, Nick Kew <ni...@webthing.com> wrote:
> On Mon, 12 May 2008 20:22:09 +0100
> Nick Kew <ni...@webthing.com> 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.
>
>> [chop]
>
> After far too long, I've revisited this issue and Tom's patch.
>
> It seems to me we can get *both* semantics at once:
>
> * Keep reslist_maint as is, preserving its existing semantics
> * Check the idle time of a resource in apr_reslist_acquire,
> and kill a resource if it's too old.
>
> There are other considerations, but a minimal effective patch
> looks like:
>
> ===================================================================
> --- apr_reslist.c (revision 659614)
> +++ apr_reslist.c (working copy)
> @@ -292,13 +292,22 @@
> {
> apr_status_t rv;
> apr_res_t *res;
> + apr_time_t now = apr_time_now();
>
> apr_thread_mutex_lock(reslist->listlock);
> /* If there are idle resources on the available list, use
> * them right away. */
> - if (reslist->nidle > 0) {
> + while (reslist->nidle > 0) {
> /* Pop off the first resource */
> res = pop_resource(reslist);
> + if (reslist->ttl && (now - res->freed >= reslist->ttl)) {
> + /* this res is expired - kill it */
> + rv = destroy_resource(reslist, res);
> + if (rv != APR_SUCCESS) {
> + apr_thread_mutex_unlock(reslist->listlock);
> + return rv; /* FIXME: this might cause unnecessary
> fails */
> + }
> + continue;
> + }
> *resource = res->opaque;
> free_container(reslist, res);
> apr_thread_mutex_unlock(reslist->listlock);
> @@ -306,8 +315,7 @@
> }
> /* If we've hit our max, block until we're allowed to create
> * a new one, or something becomes free. */
> - else while (reslist->ntotal >= reslist->hmax
> - && reslist->nidle <= 0) {
> + while (reslist->ntotal >= reslist->hmax && reslist->nidle <= 0) {
> if (reslist->timeout) {
> if ((rv = apr_thread_cond_timedwait(reslist->avail,
> reslist->listlock, reslist->timeout)) != APR_SUCCESS) {
>
> It's not perfect, but it has the advantage of neither disturbing
> the API/ABI, nor breaking promises to existing apps.
>
Looks good.
Cheers,
Henry
Re: apr_reslist semantics
Posted by Ruediger Pluem <rp...@apache.org>.
On 05/23/2008 09:28 PM, Nick Kew wrote:
> On Mon, 12 May 2008 20:22:09 +0100
> Nick Kew <ni...@webthing.com> 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.
>
>> [chop]
>
> After far too long, I've revisited this issue and Tom's patch.
>
> It seems to me we can get *both* semantics at once:
>
> * Keep reslist_maint as is, preserving its existing semantics
> * Check the idle time of a resource in apr_reslist_acquire,
> and kill a resource if it's too old.
>
> There are other considerations, but a minimal effective patch
> looks like:
>
> ===================================================================
> --- apr_reslist.c (revision 659614)
> +++ apr_reslist.c (working copy)
> @@ -292,13 +292,22 @@
> {
> apr_status_t rv;
> apr_res_t *res;
> + apr_time_t now = apr_time_now();
>
> apr_thread_mutex_lock(reslist->listlock);
> /* If there are idle resources on the available list, use
> * them right away. */
> - if (reslist->nidle > 0) {
> + while (reslist->nidle > 0) {
> /* Pop off the first resource */
> res = pop_resource(reslist);
> + if (reslist->ttl && (now - res->freed >= reslist->ttl)) {
> + /* this res is expired - kill it */
> + rv = destroy_resource(reslist, res);
> + if (rv != APR_SUCCESS) {
> + apr_thread_mutex_unlock(reslist->listlock);
> + return rv; /* FIXME: this might cause unnecessary
> fails */
> + }
> + continue;
> + }
> *resource = res->opaque;
> free_container(reslist, res);
> apr_thread_mutex_unlock(reslist->listlock);
> @@ -306,8 +315,7 @@
> }
> /* If we've hit our max, block until we're allowed to create
> * a new one, or something becomes free. */
> - else while (reslist->ntotal >= reslist->hmax
> - && reslist->nidle <= 0) {
> + while (reslist->ntotal >= reslist->hmax && reslist->nidle <= 0) {
> if (reslist->timeout) {
> if ((rv = apr_thread_cond_timedwait(reslist->avail,
> reslist->listlock, reslist->timeout)) != APR_SUCCESS) {
>
> It's not perfect, but it has the advantage of neither disturbing
> the API/ABI, nor breaking promises to existing apps.
From first glance this looks good.
Regards
Rüdiger
Re: apr_reslist semantics
Posted by Nick Kew <ni...@webthing.com>.
On Mon, 12 May 2008 20:22:09 +0100
Nick Kew <ni...@webthing.com> 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.
> [chop]
After far too long, I've revisited this issue and Tom's patch.
It seems to me we can get *both* semantics at once:
* Keep reslist_maint as is, preserving its existing semantics
* Check the idle time of a resource in apr_reslist_acquire,
and kill a resource if it's too old.
There are other considerations, but a minimal effective patch
looks like:
===================================================================
--- apr_reslist.c (revision 659614)
+++ apr_reslist.c (working copy)
@@ -292,13 +292,22 @@
{
apr_status_t rv;
apr_res_t *res;
+ apr_time_t now = apr_time_now();
apr_thread_mutex_lock(reslist->listlock);
/* If there are idle resources on the available list, use
* them right away. */
- if (reslist->nidle > 0) {
+ while (reslist->nidle > 0) {
/* Pop off the first resource */
res = pop_resource(reslist);
+ if (reslist->ttl && (now - res->freed >= reslist->ttl)) {
+ /* this res is expired - kill it */
+ rv = destroy_resource(reslist, res);
+ if (rv != APR_SUCCESS) {
+ apr_thread_mutex_unlock(reslist->listlock);
+ return rv; /* FIXME: this might cause unnecessary
fails */
+ }
+ continue;
+ }
*resource = res->opaque;
free_container(reslist, res);
apr_thread_mutex_unlock(reslist->listlock);
@@ -306,8 +315,7 @@
}
/* If we've hit our max, block until we're allowed to create
* a new one, or something becomes free. */
- else while (reslist->ntotal >= reslist->hmax
- && reslist->nidle <= 0) {
+ while (reslist->ntotal >= reslist->hmax && reslist->nidle <= 0) {
if (reslist->timeout) {
if ((rv = apr_thread_cond_timedwait(reslist->avail,
reslist->listlock, reslist->timeout)) != APR_SUCCESS) {
It's not perfect, but it has the advantage of neither disturbing
the API/ABI, nor breaking promises to existing apps.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: apr_reslist semantics
Posted by Joe Orton <jo...@redhat.com>.
On Tue, May 13, 2008 at 09:58:42AM +0100, Nick Kew wrote:
> On Tue, 13 May 2008 09:07:03 +0100
> Joe Orton <jo...@redhat.com> wrote:
> > changing each function call into
> > an indirected dynamic-symbol-lookup-and-function-call would be an
> > unmaintainable hack.
>
> But that's not the proposal on the table! Noone is suggesting
> changing any function call, API or even ABI. Merely how the
> code is loaded.
OK, great. How will it work then?
> > Since downstream users must also continue to be
> > linked against those LDAP libraries by virtue of linking against
> > libaprutil, it would also be a redundant hack.
>
> That is a misfeature of the current build procedure.
The code was explicitly designed to work like this, it's a feature which
can't be removed without breaking backwards compat with existing
downstream users. (I'm not saying I like it)
joe
Re: apr_reslist semantics
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Nick Kew wrote:
>
> Um, I wasn't thinking of multiple simultaneous backends.
> Rather that switching (the single) backend would not require
> rebuilding the whole of apr-util.
Sadly it does for "classic" ldap users because of the transparency
we offered them in choosing their behavior and API.
Of course, splitting this properly will let us normalize all of this
at the APR level, eventually reaching parity and letting us drop in
a replacement. I'm afraid that might be a ways off, though.
Re: apr_reslist semantics
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 13 May 2008 10:00:00 -0500
"William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> > Dynamic building will be a tremendous aid to anyone
> > wanting to support multiple LDAP libraries, too.
> > We have some open bugs concerning LDAP that could easily
> > be down to static linking and less-than-100%-compatible
> > library versions.
>
> My plan was a 1:1 to a specific provider, since this would break
> expectations. I'd agree with Joe that providing multiple LDAP
> back-ends would end up being a 2.0 feature :(
Um, I wasn't thinking of multiple simultaneous backends.
Rather that switching (the single) backend would not require
rebuilding the whole of apr-util.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: apr_reslist semantics
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Nick Kew wrote:
> On Tue, 13 May 2008 09:07:03 +0100
> Joe Orton <jo...@redhat.com> wrote:
>
>> changing each function call into
>> an indirected dynamic-symbol-lookup-and-function-call would be an
>> unmaintainable hack.
>
> But that's not the proposal on the table! Noone is suggesting
> changing any function call, API or even ABI. Merely how the
> code is loaded.
No - nothing will change to the user. The externally offered symbols
must remain constant, with no change in build procedures for users
who wish to use the 'classic' ldap functionality.
>> Since downstream users must also continue to be
>> linked against those LDAP libraries by virtue of linking against
>> libaprutil, it would also be a redundant hack.
>
> That is a misfeature of the current build procedure.
> I don't see why it can't be changed. Or indeed left as
> a compile-time option to users, whether to build LDAP
> and other modules as static or dynamic (and in the
> latter case, LDAP support becomes a runtime choice).
Yes; this requires additional stubs because users today must otherwise
continue to bind to ldap directly. About multiple providers however...
> Dynamic building will be a tremendous aid to anyone
> wanting to support multiple LDAP libraries, too.
> We have some open bugs concerning LDAP that could easily
> be down to static linking and less-than-100%-compatible
> library versions.
My plan was a 1:1 to a specific provider, since this would break
expectations. I'd agree with Joe that providing multiple LDAP
back-ends would end up being a 2.0 feature :(
Re: apr_reslist semantics
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 13 May 2008 09:07:03 +0100
Joe Orton <jo...@redhat.com> wrote:
> On Mon, May 12, 2008 at 04:10:14PM -0500, William Rowe wrote:
> > Like Roy, I'm frustrated with aprutil's dependency madness, and I'm
> > working right now on abstracting out apu-util into a loadable
> > module. At this point a --with-ldap build on linux FC8 is
> > producing this pile of crap as bindings for those applications with
> > no use for ldap;
>
> That is a 2.0 discussion not a 1.3 discussion. (and see msgid
> 20071123103706.GA4169@redhat.com)
>
> For 1.x, libaprutil must continue to contain functions which use
> symbols defined by the LDAP library;
Only if built --with-ldap (to state the bleedin' obvious).
> changing each function call into
> an indirected dynamic-symbol-lookup-and-function-call would be an
> unmaintainable hack.
But that's not the proposal on the table! Noone is suggesting
changing any function call, API or even ABI. Merely how the
code is loaded.
> Since downstream users must also continue to be
> linked against those LDAP libraries by virtue of linking against
> libaprutil, it would also be a redundant hack.
That is a misfeature of the current build procedure.
I don't see why it can't be changed. Or indeed left as
a compile-time option to users, whether to build LDAP
and other modules as static or dynamic (and in the
latter case, LDAP support becomes a runtime choice).
Dynamic building will be a tremendous aid to anyone
wanting to support multiple LDAP libraries, too.
We have some open bugs concerning LDAP that could easily
be down to static linking and less-than-100%-compatible
library versions.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: apr_reslist semantics
Posted by Joe Orton <jo...@redhat.com>.
On Mon, May 12, 2008 at 04:10:14PM -0500, William Rowe wrote:
> Like Roy, I'm frustrated with aprutil's dependency madness, and I'm working
> right now on abstracting out apu-util into a loadable module. At this point
> a --with-ldap build on linux FC8 is producing this pile of crap as bindings
> for those applications with no use for ldap;
That is a 2.0 discussion not a 1.3 discussion. (and see msgid
20071123103706.GA4169@redhat.com)
For 1.x, libaprutil must continue to contain functions which use symbols
defined by the LDAP library; changing each function call into an
indirected dynamic-symbol-lookup-and-function-call would be an
unmaintainable hack. Since downstream users must also continue to be
linked against those LDAP libraries by virtue of linking against
libaprutil, it would also be a redundant hack.
(same broadly goes for the XML & DBM interfaces)
joe
Re: apr_reslist semantics
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2008-05-12 at 16:39 -0500, William A. Rowe, Jr. wrote:
> Which is my point, a loadable apr_ldap.so stub which is loaded at runtime
> by applications which need it is the simplest solution. With the existing
> apr_ldap_init function, this should all be transparent.
Ah, sorry :-( I thought you wanted to avoid linking to these at all -
which of course cannot be done with F8's OpenLDAP.
Please ignore me - ENOCOFFEE :-)
--
Bojan
Re: apr_reslist semantics
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Bojan Smojver wrote:
>
> BTW, if you do link to to OpenLDAP on F8, all these things do make sense
> to OpenLDAP - they are not useless. Or did I miss something?
Of course, yes this is OpenLDAP and it uses them all [under some
circumstances] so they are not a waste...
until a non-ldap apr-bound application is run.
Which is my point, a loadable apr_ldap.so stub which is loaded at runtime
by applications which need it is the simplest solution. With the existing
apr_ldap_init function, this should all be transparent.
Bill
Re: apr_reslist semantics
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2008-05-12 at 16:10 -0500, William A. Rowe, Jr. wrote:
> Like Roy, I'm frustrated with aprutil's dependency madness, and I'm working
> right now on abstracting out apu-util into a loadable module. At this point
> a --with-ldap build on linux FC8 is producing this pile of crap as bindings
> for those applications with no use for ldap;
>
> +libldap-2.3.so.0
> +liblber-2.3.so.0
> +libresolv.so.2
> +libsasl2.so.2
> +libssl.so.6
> +libcrypto.so.6
> +libgssapi_krb5.so.2
> +libkrb5.so.3
> +libcom_err.so.2
> +libk5crypto.so.3
> +libz.so.1
> +libkrb5support.so.0
> +libkeyutils.so.1
> +libselinux.so.1
Aren't these coming from OpenLDAP:
---------------------------------------
$ ldd /usr/lib/libldap.so
linux-gate.so.1 => (0x00110000)
liblber-2.3.so.0 => /usr/lib/liblber-2.3.so.0 (0x00c83000)
libresolv.so.2 => /lib/libresolv.so.2 (0x005da000)
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x02d7f000)
libssl.so.6 => /lib/libssl.so.6 (0x004d1000)
libcrypto.so.6 => /lib/libcrypto.so.6 (0x02fb0000)
libc.so.6 => /lib/libc.so.6 (0x00744000)
libdl.so.2 => /lib/libdl.so.2 (0x008ca000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x03c7f000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00cd5000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00d54000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x00101000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00cad000)
libz.so.1 => /lib/libz.so.1 (0x008ec000)
/lib/ld-linux.so.2 (0x00721000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00b34000)
libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x006e4000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00186000)
---------------------------------------
BTW, if you do link to to OpenLDAP on F8, all these things do make sense
to OpenLDAP - they are not useless. Or did I miss something?
--
Bojan
Re: apr_reslist semantics
Posted by Graham Leggett <mi...@sharp.fm>.
Nick Kew wrote:
> A definite +1 for dynamically linking apr-util modules by default.
> For DBD and LDAP that's a no-brainer with the big dependencies,
> but it could apply more widely.
Ideally any SSL/EVP code abstraction should do the same thing.
Regards,
Graham
--
Re: apr_reslist semantics
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2008-05-12 at 17:38 -0500, William A. Rowe, Jr. wrote:
> Do folks feel we should release "an apr+apu" this friday? If 1.3.0 has
> settled in, then that is the release. If not, a final 1.2.x release
> instead, in the interim?
Given Joe's latest comments regarding --with-ldap, I would be then
inclined to say 1.3.0. Unless there are some other major dramas that
cannot be fixed before then...
--
Bojan
Re: apr_reslist semantics
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Nick Kew wrote:
>
> +1 to taking time for this. But at the moment we're in danger of
> doing a rushed/botched job on a get-it-out-for-httpd-2.2.9 agenda.
> That's basically because noone has been thinking of 1.3 as a
> release candidate until the last couple of weeks, so we haven't
> given sufficient thought to loose ends.
One more thought; if Jim in anxious to roll and we need to roll 1.2.x
that's fine by me.
With httpd-2.0, I had patched apu-config to report ldap bindings entirely
separately from the core bindings. That worked great, because next to
nothing was abstracted, and mod_ldap/util_ldap alone were bound to the
ldap bindings. The various support/ tools and core httpd loaded just fine
without all the cruft.
With httpd-2.2 and apr-1, this is now impossible, so I consider 2.2 to
be essentially broken for practical purposes (except for rolling it on
each and every machine individually). It's really somewhat shabby.
So I don't have any opinion on a 2.2.9 without apr-1.3.0 + dynamic ldap.
If folks want it now, great. I'm only keen to rip these direct bindings
out of httpd, and even out of the core of apu, leaving us with a very
clean server until a user actually uses ldap auth modules, and a release
of 1.2.x is no skin off my back.
Do folks feel we should release "an apr+apu" this friday? If 1.3.0 has
settled in, then that is the release. If not, a final 1.2.x release
instead, in the interim?
Bill
Re: apr_reslist semantics
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Nick Kew wrote:
> On Mon, 12 May 2008 16:10:14 -0500
> "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>
>> So if we take a few more days to smooth out the rough edges of 1.3.0
>> I think it's a huge win to get these things right, reslist included.
>
> +1 to taking time for this. But at the moment we're in danger of
> doing a rushed/botched job on a get-it-out-for-httpd-2.2.9 agenda.
> That's basically because noone has been thinking of 1.3 as a
> release candidate until the last couple of weeks, so we haven't
> given sufficient thought to loose ends.
>
> A definite +1 for dynamically linking apr-util modules by default.
> For DBD and LDAP that's a no-brainer with the big dependencies,
> but it could apply more widely.
Agreed, I'm thinking dbm specifically, and xlate and xml less urgently.
Bill
Re: apr_reslist semantics
Posted by Nick Kew <ni...@webthing.com>.
On Mon, 12 May 2008 16:10:14 -0500
"William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>
> So if we take a few more days to smooth out the rough edges of 1.3.0
> I think it's a huge win to get these things right, reslist included.
+1 to taking time for this. But at the moment we're in danger of
doing a rushed/botched job on a get-it-out-for-httpd-2.2.9 agenda.
That's basically because noone has been thinking of 1.3 as a
release candidate until the last couple of weeks, so we haven't
given sufficient thought to loose ends.
A definite +1 for dynamically linking apr-util modules by default.
For DBD and LDAP that's a no-brainer with the big dependencies,
but it could apply more widely.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: apr_reslist semantics
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 12, 2008, at 5:10 PM, William A. Rowe, Jr. wrote:
>
> So if we take a few more days to smooth out the rough edges of 1.3.0
> I think
> it's a huge win to get these things right, reslist included.
>
+1
Re: apr_reslist semantics
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
>
>
> On 05/12/2008 09:22 PM, Nick Kew wrote:
>>
>> 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.
>
> Or we create a new function similar to apr_reslist_timeout_set that sets
> this value (I like the second proposal more).
Agreed, manipulate this independently, provided it can be toggled in real
time (as opposed to being locked into this behavior for the lifetime of
the apr_reslist).
> Of course this would need to happen before the release of 1.3.0 if we want
> to bring this into 1.3.x.
+1 provided a patch is forthcoming shortly.
Like Roy, I'm frustrated with aprutil's dependency madness, and I'm working
right now on abstracting out apu-util into a loadable module. At this point
a --with-ldap build on linux FC8 is producing this pile of crap as bindings
for those applications with no use for ldap;
+libldap-2.3.so.0
+liblber-2.3.so.0
+libresolv.so.2
+libsasl2.so.2
+libssl.so.6
+libcrypto.so.6
+libgssapi_krb5.so.2
+libkrb5.so.3
+libcom_err.so.2
+libk5crypto.so.3
+libz.so.1
+libkrb5support.so.0
+libkeyutils.so.1
+libselinux.so.1
So if we take a few more days to smooth out the rough edges of 1.3.0 I think
it's a huge win to get these things right, reslist included.
Bill
Re: apr_reslist semantics
Posted by Ruediger Pluem <rp...@apache.org>.
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