A Quick follow up on that one. I now did it like that and it seems to work:
public void cleanup(final HttpHost host) {
enumAvailable(new PoolEntryCallback<HttpHost, NHttpClientConnection>() {
@Override
public void process(PoolEntry<HttpHost, NHttpClientConnection> entry) {
if (entry.getRoute().equals(host)) {
entry.close();
}
}
});
enumLeased(new PoolEntryCallback<HttpHost, NHttpClientConnection>() {
@Override
public void process(PoolEntry<HttpHost, NHttpClientConnection> entry) {
if (entry.getRoute().equals(host)) {
entry.close();
}
}
});
}
but of course this can pretty much kill the selectors in flight.. that’s whats
coming up sometimes:
java.nio.channels.CancelledKeyException
at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73)
at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:77)
at
org.apache.http.impl.nio.reactor.IOSessionImpl.getEventMask(IOSessionImpl.java:138)
at
org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:266)
at
org.apache.http.impl.nio.DefaultHttpClientIODispatch.onInputReady(DefaultHttpClientIODispatch.java:165)
at
org.apache.http.impl.nio.DefaultHttpClientIODispatch.onInputReady(DefaultHttpClientIODispatch.java:51)
at
org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:113)
at
org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:159)
at
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:338)
at
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:316)
at
org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:277)
at
org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:105)
at
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:584)
at java.lang.Thread.run(Thread.java:722)
Is there a better way to do this safely?
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.
>
>> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
