apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 63632] reslist kills all idle connections when acquiring a new one, not considering smax value
Date Tue, 27 Aug 2019 09:52:05 GMT

--- Comment #3 from jop <j.brunod@inwind.it> ---
(In reply to Ruediger Pluem from comment #2)
> I would argue the other way round. The reslist_maintain code needs to be
> fixed. The idea of the ttl parameter is to never ever hand out expired
> resources as they could be stale (think of situation where you know that
> after a certain period of inactivity a TCP connection will be dead). This is
> also documented in the API:
> * @param ttl If non-zero, sets the maximum amount of time in microseconds an
>  *            unused resource is valid.  Any resource which has exceeded this
>  *            time will be destroyed, either when encountered by
>  *            apr_reslist_acquire() or during reslist maintenance.
> But I agree that there is some inconsistency regarding the smax parameter.
> Either we need to kill all resources above smax during each maintenance run
> or we need to have an additional 'idle' parameter to determine after what
> time everything above smax is destroyed.

Ok so, as an additional suggestion, I would think about implementing something
like an optional validate() function pointer, so that instead of blindly
killing all connections everytime a single resource is acquired, simply check
that the acquired resource is valid before handing it out. 
I think all standard connection pools out there do it. I say this because I
think it's a bit overkill to kill and reopen all connections up to smin every
time a resource is acquired after the given TTL, it also places an additional
and useless load on the backend server, somewhat voiding the advantage of a
resource list. At least with a validate() you are sure the connection is OK
before handing it out. Also a keepalive() function pointer could be great. 
I actually implemented, both of those, client-side in my code, with a wrapper
function that does this kind of validating as a function pointer, but it could
be neat to have it in the reslist.

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

View raw message