hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roland Weber (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-747) No entry created for this pool.
Date Wed, 13 Feb 2008 17:57:08 GMT

    [ 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

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.


> 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
> java.lang.IllegalStateException: No entry created for this pool. HttpRoute[{}->]
>     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
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message