[
https://issues.apache.org/jira/browse/HTTPCLIENT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568649#action_12568649
]
Roland Weber commented on HTTPCLIENT-747:
-----------------------------------------
Hi Oleg,
I don't have cycles available to take care of it in the short term. If you
have, please go ahead.
One possible explanation is that a connection goes stale after being checked
for consistency but before the big lock of the connection pool is obtained.
That could be the case if two threads try to release the connection at about
the same time. But after your changes in HTTPCLIENT-741, only the allocating
thread should be releasing the connection, right? To catch this one would need
a second consistency check after the lock is obtained.
Another more simple explanation is that the route stored in the connection is
incorrect at release time.
cheers,
Roland
> No entry created for this pool.
> -------------------------------
>
> Key: HTTPCLIENT-747
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-747
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpConn
> Affects Versions: 4.0 Alpha 3
> Reporter: Roland Weber
> Assignee: Roland Weber
> Priority: Minor
> Fix For: 4.0 Alpha 4
>
>
> Followup to https://issues.apache.org/jira/browse/HTTPCLIENT-741, as reported
> by Sam Berlin:
> java.lang.IllegalStateException: No entry created for this pool.
> HttpRoute[{}->http://74.160.66.42:14561]
> at
> org.apache.http.impl.conn.tsccm.RouteSpecificPool.freeEntry(RouteSpecificPool.java:137)
> at
> org.apache.http.impl.conn.tsccm.ConnPoolByRoute.freeEntry(ConnPoolByRoute.java:337)
> at
> org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager.releaseConnection(ThreadSafeClientConnManager.java:230)
> at
> org.apache.http.impl.client.DefaultClientRequestDirector.execute(DefaultClientRequestDirector.java:427)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:500)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:455)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:421)
> at
> com.limegroup.gnutella.http.DefaultHttpExecutor.performRequest(DefaultHttpExecutor.java:97)
> at
> com.limegroup.gnutella.http.DefaultHttpExecutor.access$000(DefaultHttpExecutor.java:26)
> at
> com.limegroup.gnutella.http.DefaultHttpExecutor$MultiRequestor.run(DefaultHttpExecutor.java:139)
> at
> org.limewire.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1006)
> at
> org.limewire.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:549)
> at java.lang.Thread.run(Thread.java:613)
> ---
> DefaultHttpExecutor$MultiRequestor basically is just a Runnable / Cancellable
> [exposes a cancel() method] that can be cancelled from any thread. cancel
> just calls abort() on the current AbortableHttpRequest, but is called on a
> thread other than the one that's doing the client.execute(request).
> The last one is the most common exception, and seems to happen with some
> regularity. The other two we've only seen once, so may just be a memory quirk
> (we've seen some crazy bugs, including recursive NPEs while constructing an
> NPE.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
