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. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
