On Mon, 2013-12-16 at 15:06 +0100, Michael Nitschinger wrote: > On 16 Dec 2013, at 14:34, Oleg Kalnichevski <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
