Le 19/09/2013 11:10, Oleg Kalnichevski a écrit :
On Thu, 2013-09-19 at 10:05 +0200, Boris Granveaud wrote:
Le 18/09/2013 18:07, Oleg Kalnichevski a écrit :
...
Maybe I am getting too dense with age, but still fail to see a problem
here. There is already a TTL (total time to live) parameter settable at
the connection manager level, which prevents connections from being
re-used beyond a particular time limit.
Besides, I would very much rather add a protected method to
PoolingHttpClientConnectionManager allowing the expiry time to be
adjusted by a super class instead of introducing yet another parameter
that basically duplicates an existing one.
Hum, sorry you are right! I have been confused by the keepalive
management and I didn't see that the timeToLive parameter is exactly
what I need. Thanks!
Another point: in Tomcat JDBC pool, there is a validationInterval
parameter which allows to avoid checking for stale connection each time
a connection is borrowed from the pool. Basically, this check is
performed at most at the specified frequency. I have a benchmark where
the number of requests per second is doubled if I disable the stale
connection detection, but this seems not a good idea for production.
Maybe this validationInterval could provide a good compromise between
performance and reliability, what do you think?
Boris.
Hi Boris
Stale connection is known to be quite expensive and I generally
recommend disabling it. Such optimization, though, would be a valuable
contribution for sure. Please note however that presently the stale
check is not performed by the connection manager but by the protocol
handler. So, this change might require substantial efforts and entail
some design changes.
Hi Oleg,
For the moment, I'm reluctant to remove the stale check in production
because in case of a server restart or a crash, all dead connections
will be tried one time, so even with a retry handler I can get errors. I
have to test it coupled with a short time to live to see if the number
of errors is acceptable.
Boris.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
