DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42841>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42841
Summary: APR reslist algorithm fails for some database connection
pools
Product: APR
Version: HEAD
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: APR-util
AssignedTo: bugs@apr.apache.org
ReportedBy: Tom.Donovan@acm.org
When a reslist is used to manage a pool of database connections and the database
server closes inactive connections after a period of time, apr_reslist_acquire()
will return unusable connections which cause an error.
This is because the database server timeout is a "hard" timeout. Connections
which have been expired by the server cannot be used. Susceptible databases
include MySQL (per system variable 'wait_timeout'), Oracle (per profile variable
'IDLE_TIME'), and DB2 (per DB_CONNECTIVITY parameter 'IDLE_TIMEOUT').
The APR reslist algorithm presumes that resources (connections) have an
unlimited lifetime, even if ttl is specified.
A proposed patch is attached to change the meaning of two arguments to
apr_reslist_create(). There is no change to the API. The patch just changes
the timeout behavior.
With this patch:
ttl is now the maximum lifetime of a resource instead of a timer to reduce idle
connections to smax.
smax is now the maximum number of idle resources (including both expired and
un-expired) instead of the minimum.
The patch changes the behavior of apr_reslist_acquire():
It will never return an expired resource.
If there are one or more idle expired resources - the oldest one is destroyed
and a new (replacement) resource is returned instead.
The patch also changes the behavior of reslist_maint() which is called by
apr_reslist_release()
The number of idle resources in the list is always reduced to smax. Excess idle
resources no longer linger for ttl.
The definitions of hmax and min remain unchanged:
hmax is still the maximum number of resources, including all idle and in-use
resources.
min is still the minimum number of idle resources - unless creating a new
resource will cause hmax to be exceeded, which can happen when the number of
in-use resources + min > hmax.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
|