On Thu, 2012-03-29 at 13:25 -0700, Cory Lum wrote: > Thanks Oleg, I'll raise the bug. > > Regarding HttpUriRequest#abort, was it not resolved via > https://issues.apache.org/jira/browse/HTTPCLIENT-881? (I'm on 4.1.2). Even if > I did use abort, shouldn't the pool not use an aborted connection? >
If the abort method is called from another thread while the request execution is still ongoing, the exception can still be thrown, even if the connection has been released back to the connection manager. Oleg > -----Original Message----- > From: Oleg Kalnichevski [mailto:[email protected]] > Sent: Thursday, March 29, 2012 4:10 PM > To: HttpClient User Discussion > Subject: RE: Bad connection used by ThreadSafeClientConnManager > > On Wed, 2012-03-28 at 14:54 -0700, Cory Lum wrote: > > Thanks Oleg. I do not have abort in code. Also, sometimes I would get > > this exception > > > > java.lang.NullPointerException > > at > > org.apache.http.impl.client.DefaultUserTokenHandler.getAuthPrincipal(DefaultUserTokenHandler.java:91) > > at > > org.apache.http.impl.client.DefaultUserTokenHandler.getUserToken(DefaultUserTokenHandler.java:72) > > at > > org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:516) > > at > > org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820) > > at some.package.SomeClass.execute(SomeClass.java:123) > > > > -or- > > > > java.lang.NullPointerException > > at > > org.apache.http.impl.client.DefaultUserTokenHandler.getUserToken(DefaultUserTokenHandler.java:79) > > at > > org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:516) > > at > > org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820) > > at some.package.SomeClass.execute(SomeClass.java:123) > > > > Cory, > > Please raise a JIRA for NPEs thrown in DefaultUserTokenHandler. This is > clearly a bug in HttpClient. > > > What else can trigger such an exception? > > > > Only an _explicit_ connection shutdown (usually through > HttpUriRequest#abort) and nothing else. I double-checked. > > Oleg > > > > > > > -----Original Message----- > > From: Oleg Kalnichevski [mailto:[email protected]] > > Sent: Wednesday, March 28, 2012 3:18 PM > > To: HttpClient User Discussion > > Subject: RE: Bad connection used by ThreadSafeClientConnManager > > > > On Wed, 2012-03-28 at 10:02 -0700, Cory Lum wrote: > > > Sam, > > > > > > You're correct that I'm only using HTTP so it beats me why HttpClient is > > > trying to get SSL information... > > > > > > The API was a bit different in HttpClient 3.X where I used > > > MultiThreadedHttpConnectionManager and never had this exception. It's > > > only with HttpComponent 4.x. > > > I assume that the connection manager would handle this so why is it > > > necessary to implement a background enviction thread? > > > > > > Stepping through the implementation of DefaultRequestDirectory.java, the > > > connection was actually valid for tryConnect() and tryExecute() calls and > > > it was able to obtain a response but somehow chokes immediately > > > afterwards within DefaultRequestDirectory.execute()? > > > > > > Thanks, > > > Cory > > > > > > > Hi Cory > > > > (1) 'org.apache.http.impl.conn.ConnectionShutdownException' is thrown > > only when the connection has been shut down by the user. Are you using > > HttpUriRequest#abort method anywhere in your code? > > > > (2) HttpClient tries to access the SSL session in order to find out > > whether or not the underlying connection is state-full (created in a > > security context of a particular user) > > > > Hope this helps > > > > Oleg > > > > > -----Original Message----- > > > From: Sam Crawford [mailto:[email protected]] > > > Sent: Wednesday, March 28, 2012 12:15 PM > > > To: HttpClient User Discussion > > > Subject: Re: Bad connection used by ThreadSafeClientConnManager > > > > > > Hi Cory, > > > > > > I don't think your debug log necessarily relates to the exception... > > > Your stacktrace indicates that the error was thrown for an SSL > > > connection, but your log indicates you were sending plain HTTP requests. > > > > > > Anyway, servers will commonly allow connections to be kept alive, but > > > only for a short time. After that time they will close the connections, > > > and the client (HttpClient here) may not be notified that the connection > > > was closed (or it may be left in a half-open state). > > > > > > For this reason, you may want to have a background thread that is > > > forcibly closing connections that have been idle longer than X > > > seconds. It's a common problem - check out the example at > > > http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/http > > > client/src/examples/org/apache/http/examples/client/ClientEvictExpir > > > edConnections.java > > > > > > Thanks, > > > > > > Sam > > > > > > > > > > > > On 27 March 2012 21:24, Cory Lum <[email protected]> wrote: > > > > Hi guys, > > > > > > > > > > > > > > > > I'm using ThreadSafeClientConnManager from HttpComponents library for > > > > multithreaded post requests and I'm running into the following > > > > exception. > > > > > > > > java.io.InterruptedIOException: Connection has been shut down > > > > > > > > at > > > > org.apache.http.impl.client.DefaultRequestDirector.execute(Default > > > > Requ > > > > estDirector.java:543) > > > > > > > > at > > > > org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHtt > > > > pCli > > > > ent.java:820) > > > > > > > > at some.package.SomeClass.execute(SomeClass.java:123) > > > > > > > > Caused by: org.apache.http.impl.conn.ConnectionShutdownException > > > > > > > > at > > > > org.apache.http.impl.conn.AbstractClientConnAdapter.assertValid(Ab > > > > stra > > > > ctClientConnAdapter.java:154) > > > > > > > > at > > > > org.apache.http.impl.conn.AbstractClientConnAdapter.getSSLSession( > > > > Abst > > > > ractClientConnAdapter.java:270) > > > > > > > > at > > > > org.apache.http.impl.client.DefaultUserTokenHandler.getUserToken(D > > > > efau > > > > ltUserTokenHandler.java:80) > > > > > > > > at > > > > org.apache.http.impl.client.DefaultRequestDirector.execute(Default > > > > Requ > > > > estDirector.java:516) > > > > > > > > > > > > > > > > Here's the DEBUG output before the exception which looks fine. > > > > > > > > [org.apache.http.impl.conn.tsccm.ConnPoolByRoute][DEBUG] > > > > [HttpRoute[{}->http://localhost:8080]] total kept alive: 2, total > > > > issued: 0, total allocated: 2 out of 20 > > > > > > > > [org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager][DEBU > > > > G] Get connection: HttpRoute[{}->http://localhost:8080], timeout = > > > > 0 > > > > > > > > [org.apache.http.impl.conn.tsccm.ConnPoolByRoute][DEBUG] Getting > > > > free connection [HttpRoute[{}->http://localhost:8080]][null] > > > > > > > > [org.apache.http.impl.conn.tsccm.ConnPoolByRoute][DEBUG] > > > > [HttpRoute[{}->http://localhost:8080]] total kept alive: 1, total > > > > issued: 1, total allocated: 2 out of 20 > > > > > > > > [org.apache.http.impl.conn.tsccm.ConnPoolByRoute][DEBUG] Getting > > > > free connection [HttpRoute[{}->http://localhost:8080]][null] > > > > > > > > [org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager][DEBUG] > > > > Released connection is reusable. > > > > > > > > [org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager][DEBUG] > > > > Released connection is not reusable. > > > > > > > > [org.apache.http.impl.conn.tsccm.ConnPoolByRoute][DEBUG] Releasing > > > > connection [HttpRoute[{}->http://localhost:8080]][null] > > > > > > > > [org.apache.http.impl.conn.tsccm.ConnPoolByRoute][DEBUG] Pooling > > > > connection [HttpRoute[{}->http://localhost:8080]][null]; keep > > > > alive indefinitely > > > > > > > > [org.apache.http.impl.conn.tsccm.ConnPoolByRoute][DEBUG] Releasing > > > > connection [HttpRoute[{}->http://localhost:8080]][null] > > > > > > > > [org.apache.http.impl.conn.tsccm.ConnPoolByRoute][DEBUG] Notifying > > > > no-one, there are no waiting threads > > > > > > > > [org.apache.http.impl.conn.tsccm.ConnPoolByRoute][DEBUG] Notifying > > > > no-one, there are no waiting threads > > > > > > > > > > > > > > > > Any ideas what might be the problem? Looking at the source > > > > code(DefaultRequestDirector.java), if a connection is not reusable, why > > > > does it still try to get the user token to set into connection? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Cory > > > > > > -------------------------------------------------------------------- > > > - 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] > > > > > > > > > > > --------------------------------------------------------------------- > > 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] > > > > > > --------------------------------------------------------------------- > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
