Btw, sorry for asking so many questions on that specific topic :) On 16 Dec 2013, at 17:11, Oleg Kalnichevski <[email protected]> wrote:
> 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. > Sounds good! Does it get cleaned up by httpcore at some point (“when? - through a configurable interval?”) or do I need to clean it up? > 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]
