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. > 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. > - Is there something I need to be aware of? > I cannot think of anything special. You just need to be mindful of having to deal with connection release in case of abnormal execution flows as well as normal. Whereas it is trivial to ensure resources deallocation with a try-finally when executing in a context of a thread, exception handling can get very tricky very fast with an event driven model. > I thought about iterating over the Entries, but there doesn’t seem to be a > way to do so. I’m using 4.3. If you are interested in the code, it’s here: > https://gist.github.com/daschl/7985206 .. it will be open source anyway (this > is part of a rework of the sdk couchbase driver) but I haven’t pushed it out > there yet. > BasicNIOConnPool provides protected methods to enumerate leased and available connections. Those methods are not made public by default to not tempt people into messing with the internals of the connect pool without a good reason. So, you need to extend the default pool implementation. Generally I would always expect users to extend AbstractNIOConnPool instead of using ultra-basic BasicNIOConnPool > If you have any other remarks on how the code is used please shoot. Cheers, I would probably caution against the (ab)use of BasicAsyncResponseConsumer due to its buffering message content in memory. You might want to consider using a custom HttpAsyncResponseConsumer that can digest response content on-the-fly chunk by chunk. This would also enable you to consume content of Content-Length delimited and identity encoded messages directly from the underlying NIO channel without _any_ intermediate buffering. Hope this helps Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
