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?
-----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]
