hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: BasicNIOConnPool Connection Lease
Date Mon, 16 Dec 2013 16:11:40 GMT
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 <olegk@apache.org> 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: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message