On Fri, 2013-09-20 at 10:27 +0200, Boris Granveaud wrote: > 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. >
Boris, A much better alternative to the stale check would be a policy of pro-active eviction of expired (and idle) connections. See this section of the tutorial for details: http://hc.apache.org/httpcomponents-client-4.3.x/tutorial/html/connmgmt.html#d5e405 Please note that one does not really have to use a separate thread to enforce such a policy. Calling #closeExpiredConnections every one in a while from the same thread after a period of long inactivity should be perfectly sufficient. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
