hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: BasicNIOConnPool Connection Lease
Date Mon, 16 Dec 2013 14:32:53 GMT
On Mon, 2013-12-16 at 15:06 +0100, Michael Nitschinger wrote:
> On 16 Dec 2013, at 14:34, Oleg Kalnichevski <olegk@apache.org> wrote:
> 
> > On Mon, 2013-12-16 at 11:56 +0100, Michael Nitschinger wrote:
> >> Hi folks (looks like my first post wasn’t acknowledged by the mailing list
service since it overlapped with subscribing),
> >> 
> >> I’ve posted an enhancement request for the docs shown here https://issues.apache.org/jira/browse/HTTPCORE-369
but I still have troubles making it work in general. 
> >> 
> >> So, basically I’m having a List<HttpHost> where I round-robin and send
it through the AsyncRequester. This all works great, but during runtime this list can change.
Adding is easy because it will pick it up on the fly. I’m more thinking about removing HttpHosts
from this list and the underlying BasicNIOConnPool management.
> >> 
> > 
> > Hi Michael
> > 
> > HttpAsyncRequester provides several convenience methods that take full
> > care of connection leasing and releasing automatically. In case you want
> > to exert a greater control over the process of connection allocation /
> > deallocation you might want to interact with the pool directly. You get
> > more control at the price of greater complexity.
> 
> Hi Oleg
> 
> thanks for your initial response. I’ve been looking at the HttpAsyncRequester for some
time now but I think - as you said - it doesn’t help in my case? I need to release all connections,
wether available or leased at a specific point in time. 
> 
> > 
> >> I think I have a few questions:
> >> 	- What is the preferred way to deal with connections that need to be removed
from the pool?
> > 
> > I cannot think of any special requirements other than making sure to
> > always return a leased connection back to pool regardless of the
> > execution flow and operation result. If you want to have the connection
> > removed from the pool, simply close it prior to returning it back.
> 
> That makes sense. I guess something isn’t clear in my understanding: does releasing
mean the underlying socket is also closed? 

No, it does not. It merely implies the connection lease is finished.
However one can release connections closed if its re-use is unwanted.

> Or it is just available to lease from somebode else. 

Yes, it just makes it available for re-use by another consumer.

> Because I really need to close the underlying sockets (the use case is: a node has been
removed out of the cluster, but in theory it could still accept a tcp/http connection attempt).
> 
> What could also work is to just tell by configuration that a connection, if idle for
N minutes, just gets removed? 

Just call #closeIdle(). You might want to do it from a dedicated monitor
thread if you want the pool purged periodically.

> is that possible? Because then I don’t need to take care of and close idle sockets..
and if there is really so less traffic on the box then they maybe also don’t care about
that initial socket connect again.
> 

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