You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Aaron Bannert <aa...@clove.org> on 2006/09/06 19:30:56 UTC
Re: reslist API does not provide proper size regulation
On Thu, Aug 31, 2006 at 07:06:10AM +0000, Christian BOITEL wrote:
> Following my discussion on this topic with rpluem on bugzilla, i am posting this one to submit you a change in the reslit pool management to ensure proper pool size regulation and some API changes to better handle this part of the list management.
>
> See my initial toughts on http://issues.apache.org/bugzilla/show_bug.cgi?id=40348
The failure of the reslist to shrink back down after load subsides does
sound like a valid bug to me. If you could provide a patch that changes the
maint routine to search from the end of the list, and also a change to
make the list behave like a stack instead of a queue, that would be great.
As for changing the meaning of TTL, I'm not so sure that's needed after
the above changes. If you need to invalidate a resource, you can use the
apr_reslist_invalidate() routine. To implement a strict maximum lifetime
for your resources, simply check your own timer after aquiring a new
resource, and call the invalidate routine if it's too old, and then
try to get another resource.
-aaron
Re: Fwd: reslist API does not provide proper size regulation
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Christian BOITEL <ch...@yahoo.fr>:
> Should i submit a new case if bugzilla to integrate this patch ?
Yes, please. That way the bug report would not fall through the
cracks. If you can, check if this problem exists in the trunk as well
and then attach the patch for that.
--
Bojan
Fwd: reslist API does not provide proper size regulation
Posted by Christian BOITEL <ch...@yahoo.fr>.
Seems i forgot to send reply to the dev list
---------- Forwarded message ----------
From: Christian BOITEL <ch...@yahoo.fr>
Date: 6 juin 2007 17:17
Subject: Re: reslist API does not provide proper size regulation
To: Aaron Bannert <aa...@clove.org>
Find below the suggested patch for the 1.2.8: it took me time to answer for
i had the patch for 1.2.7 version but 1.2.8 was released and didn't find
time to investigate if patch would apply to 1.2.8 (time was found when i had
to upgrade to 1.2.8)
As you can see patch is quite simple and applies only to misc/apr_reslist.c.
My testes with Apache/Tomcat have shown that reslist now regulates (goes
down) even if an on-going activity is maintained.
Should i submit a new case if bugzilla to integrate this patch ?
Thank you,
Christian.
--- apr_reslist.c.original 2005-02-04 21:45:35.000000000 +0100
+++ apr_reslist.c 2007-06-06 09:22:14.000000000 +0200
@@ -80,7 +80,7 @@
*/
static void push_resource(apr_reslist_t *reslist, apr_res_t *resource)
{
- APR_RING_INSERT_TAIL(&reslist->avail_list, resource, apr_res_t, link);
+ APR_RING_INSERT_HEAD(&reslist->avail_list, resource, apr_res_t, link);
resource->freed = apr_time_now();
reslist->nidle++;
}
@@ -207,14 +207,15 @@
now = apr_time_now();
while (reslist->nidle > reslist->smax && reslist->nidle > 0) {
/* Peak at the first resource in the list */
- res = APR_RING_FIRST(&reslist->avail_list);
+ res = APR_RING_LAST(&reslist->avail_list);
/* See if the oldest entry should be expired */
if (now - res->freed < reslist->ttl) {
/* If this entry is too young, none of the others
* will be ready to be expired either, so we are done. */
break;
}
- res = pop_resource(reslist);
+ APR_RING_REMOVE(res, link);
+ reslist->nidle--;
reslist->ntotal--;
rv = destroy_resource(reslist, res);
free_container(reslist, res);
2006/9/6, Aaron Bannert <aa...@clove.org>:
>
> On Thu, Aug 31, 2006 at 07:06:10AM +0000, Christian BOITEL wrote:
> > Following my discussion on this topic with rpluem on bugzilla, i am
> posting this one to submit you a change in the reslit pool management to
> ensure proper pool size regulation and some API changes to better handle
> this part of the list management.
> >
> > See my initial toughts on
> http://issues.apache.org/bugzilla/show_bug.cgi?id=40348
>
> The failure of the reslist to shrink back down after load subsides does
> sound like a valid bug to me. If you could provide a patch that changes
> the
> maint routine to search from the end of the list, and also a change to
> make the list behave like a stack instead of a queue, that would be great.
>
>
> As for changing the meaning of TTL, I'm not so sure that's needed after
> the above changes. If you need to invalidate a resource, you can use the
> apr_reslist_invalidate() routine. To implement a strict maximum lifetime
> for your resources, simply check your own timer after aquiring a new
> resource, and call the invalidate routine if it's too old, and then
> try to get another resource.
>
> -aaron
>
>
Re : reslist API does not provide proper size regulation
Posted by Christian BOITEL <ch...@yahoo.fr>.
I will provide a patch for the stack implementation of reslit: to be posted on the bug referenced in my first mail.
For the second part, i simply suggest to implement a maximum lifetime feature alike an acquire timeout feature was added in revision 58964 of apr_reslist.c:
+> add a new API call say "apr_reslist_maxlifetime_set" alike the apr_reslist_timeout_set(xx)
+> change reslist_acquire functions to implement this maxlifetime feature if set
So if one wants to use a lifetime feature, he will simply have to call apr_reslist_timeout_set(xx). Otherwise, default behaviour will remain.
----- Message d'origine ----
De : Aaron Bannert <aa...@clove.org>
À : Christian BOITEL <ch...@yahoo.fr>
Cc : dev@apr.apache.org
Envoyé le : Mercredi, 6 Septembre 2006, 7h30mn 56s
Objet : Re: reslist API does not provide proper size regulation
On Thu, Aug 31, 2006 at 07:06:10AM +0000, Christian BOITEL wrote:
> Following my discussion on this topic with rpluem on bugzilla, i am posting this one to submit you a change in the reslit pool management to ensure proper pool size regulation and some API changes to better handle this part of the list management.
>
> See my initial toughts on http://issues.apache.org/bugzilla/show_bug.cgi?id=40348
The failure of the reslist to shrink back down after load subsides does
sound like a valid bug to me. If you could provide a patch that changes the
maint routine to search from the end of the list, and also a change to
make the list behave like a stack instead of a queue, that would be great.
As for changing the meaning of TTL, I'm not so sure that's needed after
the above changes. If you need to invalidate a resource, you can use the
apr_reslist_invalidate() routine. To implement a strict maximum lifetime
for your resources, simply check your own timer after aquiring a new
resource, and call the invalidate routine if it's too old, and then
try to get another resource.
-aaron