On Thu, 2016-10-27 at 12:23 +0200, Joan Balagueró wrote: > Hello, > > After working in production with the async client (instead of the blocking > one) everything seems ok, except that now I can see this error > intermitently: > > java.util.concurrent.TimeoutException > at > org.apache.http.nio.pool.AbstractNIOConnPool.processPendingRequest(AbstractN > IOConnPool.java:364) > at > org.apache.http.nio.pool.AbstractNIOConnPool.processNextPendingRequest(Abstr > actNIOConnPool.java:344) > at > org.apache.http.nio.pool.AbstractNIOConnPool.release(AbstractNIOConnPool.jav > a:318) > at > org.apache.http.impl.nio.conn.PoolingNHttpClientConnectionManager.releaseCon > nection(PoolingNHttpClientConnectionManager.java:303) > at > org.apache.http.impl.nio.client.AbstractClientExchangeHandler.releaseConnect > ion(AbstractClientExchangeHandler.java:239) > at > org.apache.http.impl.nio.client.MainClientExec.responseCompleted(MainClientE > xec.java:387) > at > org.apache.http.impl.nio.client.DefaultClientExchangeHandlerImpl.responseCom > pleted(DefaultClientExchangeHandlerImpl.java:168) > at > org.apache.http.nio.protocol.HttpAsyncRequestExecutor.processResponse(HttpAs > yncRequestExecutor.java:436) > at > org.apache.http.nio.protocol.HttpAsyncRequestExecutor.inputReady(HttpAsyncRe > questExecutor.java:326) > at > org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNH > ttpClientConnection.java:265) > at > org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODi > spatch.java:81) > at > org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODi > spatch.java:39) > at > org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODis > patch.java:114) > at > org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:1 > 62) > at > org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIORe > actor.java:337) > at > org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOR > eactor.java:315) > at > org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor > .java:276) > at > org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:10 > 4) > at > org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(Abs > tractMultiworkerIOReactor.java:588) > at java.lang.Thread.run(Thread.java:745) > > It seems that the pool is exhausted at this point. > > The setup of both pools is similar. MaxConnections to 600, > ConnectionRequestTimeout' is set to 1 (because I don't want to wait for a > pooling connection to be free), an IdleConnectionsHandler, etc. >
This looks wrong to me. I think I already explained that. > I'm not sure if some connections are not being closed. With the blocking > client one manually released the connection to the pool, but with the async > one I'm not closing connections explicitly (so I suppose this is done > automatically by the async client). > > The point is this error was not present with the blocking client. If I'm not > wrong, with the async client the possibility to exhaust the pool should be > more difficult because every time the server is not sending tcp packets the > thread is released and used for other connections. > > Well, whatever the reason I'm going to enable http traces. Since my client > only permitts updates once a week, I want to be sure that I'm enabling the > http traces correctly (otherwise I will have to wait one more week). > > With the blocking client I enabled traces putting these lines in the > log4j.xml file (and it worked). Is the same procedure with the async client? > > <logger name="org.apache.http"> > <level value="debug"/> > </logger> > > <logger name="org.apache.http.wire"> > <level value="debug"/> > </logger> > Logging configuration should be the same as for blocking HC. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
