Le 18/09/2013 18:07, Oleg Kalnichevski a écrit :
On Wed, 2013-09-18 at 17:25 +0200, Boris Granveaud wrote:
...
Connection manager's job is to keep track of available persistent
connections and enforce certain time-to-live constraints for those
connections. It is not meant to police busy connections leased by worker
threads.
Nothing prevents you from creating a custom connection manager, though,
tailored specifically to your application needs.
My intention is not to close busy connections but to enforce a maxAge
policy when the connection is released to the pool. I see this as
complementary to keepalive.
Sure I could extend PoolingHttpClientConnectionManager but this implies
some code duplication (at least releaseConnection) and reflection to
access CPoolEntry.
My point is that it is difficult to add this feature externally, but it
could be easily integrated as a standard behavior as does Tomcat JDBC
Pool for example (see maxAge parameter
http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Tomcat_JDBC_Enhanced_Attributes).
Boris.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
