hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Berlin (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-747) No entry created for this pool.
Date Sat, 15 Mar 2008 05:14:26 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579008#action_12579008

Sam Berlin commented on HTTPCLIENT-747:

Some more investigation & some (possible?) bugs:

It doesn't look like entries are cleaned up correctly if the socket connection fails.  DefaultClientRequestDirector.execute
allocates an entry for a route before opening a connection.  Then if there's an exception
while opening the socket, it doesn't look like the entry is freed up.  That means that subsequent
requests to the same route will fail (if it's over the maximum limit per host).  This explains
why it took so long to create a third entry after the first two failed -- it happened whenever
the system just-so-happened to GC.    (I suspect this is also a problem with exceptions during
normal i/o exchange, but I'm not sure.)  

It also doesn't look like 'abort' will correctly terminate a connection that's waiting to
receive a ManagedClientConnection from the ClientConnectionManager.  There's an abort sequence
set on the HttpUriRequest, but it's set to be the ManagedClientConnection, which is only created
when allocateConnection returns.  This explains why it tried to create an entry after an abort
was called, because the wait-for-connection didn't finish.  Normally I would suggest requiring
the caller to call Thread.interupt() to abort the wait, but that isn't terribly safe, especially
with I/O being performed on that thread -- there's no way to know from the outside if the
internals have succeeded in getting a connection and moved onto I/O.  There's two ways of
fixing it that I can see -- one is to add a releaseTrigger prior to calling allocateConnection
that just calls Thread.interrupt(), and then overwriting it afterwards.  Another way is to
pass the AbortableHttpRequest down the chain eventually into ConnPoolByRoute.getEntry and
let it install a more proper releaseTrigger , probably using a method in WaitingThread that
signals completion but has await return false (it could also use Thread.interrupt, I'm just
not the biggest fan of that method).

I'm still boggled by the freeEntry call.  It's as if a connection succeeded, but one with
an entirely different RouteSpecificPool.  No clue on how to explain that one.

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