On Mon, 2013-12-16 at 16:49 +0100, Michael Nitschinger wrote: > 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). >
Sure. Try calling PoolEntry#updateExpiry(0, TimeUnit.MILLISECONDS). This should render the pool entry expired immediately. Oleg > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
