In addition to my inline notes, another thought came to my mind: Is it possible to - instead of closing the connection apruptly - maybe set the expiry to “now” on those and then have the pool cleaning up? The problem is I’m building a client library and I dont want to have a monitor thread running (and there is one for the reactor and N workers already running).
Maybe that approach is less destructive? I dont mind if it takes 30 secs or so to clean them up, but it needs to be done at some point. On 16 Dec 2013, at 15:58, Oleg Kalnichevski <[email protected]> wrote: > On Mon, 2013-12-16 at 15:21 +0100, Michael Nitschinger wrote: >> 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) >> > > Yes, that is the price for shutting down a connection mid-air (so to > speak). > Makes sense, yeah! >> Is there a better way to do this safely? >> > > You might just configure I/O reactor to silently ignore > CancelledKeyException. How can I do that? Am I right that I’d need to go pretty deep into the IOReactor thing to do that? > A more complex, but likely more proper way would > be to create a custom ConnectionReuseStrategy that is aware of unwanted > connection routes or unwanted connection instances. > ConnectionReuseStrategy can get hold of the underlying connection object > from the HttpContext instance passed in as a parameter. > Do you have an example on that? That sounds like a good approach but I guess I need a starting point :) > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
