On Wed, 2013-09-18 at 16:33 +0200, Boris Granveaud wrote:

...

> >> I'm not very comfortable with this solution because of these thread
> >> synchronization issues. I also have to do the same on idle connections
> >> and each enumeration, even if it is fast, locks the pool. It is a pity
> >> that it is not possible to alter the behavior of
> >> PoolingHttpClientConnectionManager.releaseConnection.
> >>
> >> Here is my complete code if you see what's wrong:
> >>
> > There is probably nothing wrong with your code. If you intend to shut
> > down connections 'midair' so to speak, this is what you have to live
> > with. Changing #releaseConnection will not help given that time to live
> > and expiry attributes apply to idle connections only.
> As far as I understand, #releaseConnection resets the connection expiry 
> date with the keepalive value because the connection has just been used. 
> So if I was able to remove this behavior, the connection will "expire" 
> for example 60 seconds after its creation even if it is intensively used.
> 
> Or I could let the keepalive and expiry management, and add something 
> like this:
> 
>     public void releaseConnection(
> (...)
>                  if (conn.isOpen()) {
>                      entry.setState(state);
>                      entry.updateExpiry(keepalive, tunit != null ? tunit 
> : TimeUnit.MILLISECONDS);
> 
>                      if (System.currentTimeMillis() - entry.getCreated() 
>  > maxAge) {
>                          entry.closeConnection();
>                      }
>                  }
> 
> Maybe would it be interesting to make this maxAge parameter standard in 
> PoolingHttpClientConnectionManager. What do you think?
> 
> Boris.
> 

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.

Oleg



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to