hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Question on HC Connection pooling - PoolEntry
Date Tue, 05 Feb 2013 12:47:24 GMT
On Tue, 2013-02-05 at 16:26 +0530, Asankha C. Perera wrote:
> Hi Oleg
> >> public synchronized void updateExpiry(final long time, final TimeUnit
> >> tunit) {
> >>           Args.notNull(tunit, "Time unit");
> >>           this.updated = System.currentTimeMillis();
> >>           long newExpiry;
> >>           if (time > 0) {
> >>               newExpiry = this.updated + tunit.toMillis(time);
> >>           } else {
> >>               newExpiry = Long.MAX_VALUE;
> >>           }
> >>           this.expiry = Math.min(newExpiry, this.validUnit);
> >>       }
> >>
> > Hi Asankha
> >
> > Let's say a pool entry is created at 10:00 with the total time to live
> > of 10 minutes. The validUntil value is set to 10:10. Let's say at 10:05
> > #updateExpiry takes 10 minutes as input thus making newExpiry equal to
> > 10:15. Should not validUntil still apply and take precedence over
> > newExpiry?
> >
> > Oleg
> That's what I was wondering, and I thought the newExpiry should take 
> precedence, since each time I re-use a connection, I'd typically want to 
> extend its life time. I guess re-using connections is my objective when 
> using a connection pool, and thus, with each re-use the life time should 
> extend, unless some request causes a connection close or non-reusable 
> event where its discarded.
> 
> When I created the original connection I state that it can be reused 
> within another 10 minutes - i.e. until 10:10. When I do re-use it at 
> 10:05, if I am to call updateExpiry() again, that indicates that I want 
> to now "update" the expiry time which is currently set. Now if I say I 
> want to re-use this again in the next 10 minutes, i.e. until 10:15, the 
> new expiry time should be the max of validUntil and newExpiry
> 
> thanks and regards
> asankha
> 

Asankha

This is how TTL settings work in HttpClient and I am afraid we should
keep it for the compatibility sake. However, all you have to do to make
the pool work in the way you have described is to disable TTL (by using
-1 value) and manage expiration time with #updateExpiry.

Hope this helps

Oleg



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message