Bug 40348 - apr_reslist ttl setting not enough to regulate pool size
Summary: apr_reslist ttl setting not enough to regulate pool size
Status: RESOLVED INVALID
Alias: None
Product: APR
Classification: Unclassified
Component: APR-util (show other bugs)
Version: 1.2.7
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache Portable Runtime bugs mailinglist
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-29 16:44 UTC by Christian BOITEL
Modified: 2007-08-13 02:12 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian BOITEL 2006-08-29 16:44:53 UTC
Say you use apr_reslist_xxx function set and configure a pool of connections 
to a back-end system: hmax set to 100, smax set to 25 and ttl set to 300 
(seconds).

Now, imagine the following usual scenario:
1/ your normal load is such that no more than 10 connections are required at a 
time
2/ once a day, you experiment peak loads that forces the pool to grow to 50 
connections for say an hour

One would expect the pool to shrink back to 25 connections (smax setting) when 
load has returned back to normal. It will not.

This is due to the way the pool is used: acquire will pop a connection from 
the list (first entry) and release will push connection back to the list 
(added to the tail).
=> if your load is such that you use all connections in the pool within ttl 
setting, then pool will never shrink
=> pool will shring only if you experiment no load for the ttl setting (and we 
usually hope to have far more)

If release was adding the connection back to the head of the pool, then pool 
size regulation can occur (reslit_maint function will have to be updated to 
start looking at entries at the tail of the ring).
=> this way, if no more than 10 connections are used at a time, then only the 
first 10 connections in the pool will be used and the maintenance routine will 
clean the all but first 25 connections.

By the way, i would actually change the reslit management such that:
- ttl setting would mean "maximum time a resource may stay in the pool" 
(closer to time to live meaning)
- inactivity setting would mean "release resource if not used with the timeout 
specified

I would like to contribute a patch for this but don't know how to handle the 
change in the API if ttl/inactivity are to be handled. Would like your 
suggestions on this. Mine follows:
- keep the current apr_reslist_create API as is but make the original ttl 
setting to match new "inactivy" setting (this is probably what users of the 
API have though of it)
- provide an additional function call to set the ttl setting if needed by 
someone

This would then ensure Apache httpd mod_dbd and mod_proxy (which uses reslist) 
do provide a load adaptive service.
Comment 1 Ruediger Pluem 2006-08-29 19:47:30 UTC
I do not want to discourage you, but please discuss this on dev@apr.apache.org.
Bugzilla is the wrong place to do this.
Comment 2 Christian BOITEL 2006-08-31 06:36:23 UTC
I consider the fact that pool size regulation cannot occur as a bug: this is 
why i logged it to bugzilla. To fix this one, i can provide a quick patch 
which simply makes sure released pool object are added first in the list 
instead of being tailed.

Otherwise, you are right when considering discussion on API changes to 
implement a ttl/inactivity scheme: i will take some time posting discussion on 
the dev list.
Comment 3 Ruediger Pluem 2007-08-06 04:35:05 UTC
As discussed on http://www.mail-archive.com/dev@apr.apache.org/msg18448.html
committed the patch to trunk as r563103
(http://svn.apache.org/viewvc?view=rev&rev=563103).
Comment 4 Ruediger Pluem 2007-08-13 02:12:07 UTC
Backported to 1.2.x as r565277 (http://svn.apache.org/viewvc?view=rev&rev=565277).