hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Becke (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-633) MultiThreadedHttpConnectionManager does not properly respond to thread interrupts
Date Fri, 16 Feb 2007 06:16:05 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473624
] 

Michael Becke commented on HTTPCLIENT-633:
------------------------------------------

I did a little more digging on this last night and have narrowed down our choices for correctly
responding to external interrupts:

 - Change from using interrupt to ConnectionPool.wait() and ConnectionPool.notifyAll().  This
would allow us to correctly identify interrupts and handle them appropriately.  There are
two downsides however.  1) We lose the FIFO nature of the waiting threads.  2) We significantly
reduce the performance of the ConnectionPool since all threads would have to be notified on
any connection release.

 - Switch to nested locking, one for the connection pool and another for the individual host
pools.  This would allow for finer grained control of waiting threads.  Again there are downsides.
 FIFO would be lost.  Also, given the inherent limitations of Java monitors the only way to
correctly implement this would be with mutexes.  Since we're not using 1.4 we would have to
implement these ourselves.

 - The third option is to create a way to determine who interrupted the waiting thread: the
connection pool or some other thread.  We could then cleanup appropriately and re-throw the
InterruptedException if we want.  The only issue here is that I don't see a foolproof way
to do this.  If a waiting thread were interrupted by the connection pool and then again by
an external thread before it resumed processing it would not be able to accurately tell who
interrupted.  I'm assuming this is a fairly rare occurrence, but it could technically still
happen.

 - The fourth option is to ignore external interrupts and fix the bug where they corrupt the
internal state of the ConnectionManager.

At this point my preference is for either 3 or 4.  Does anyone see a better way to go?

Mike

> MultiThreadedHttpConnectionManager does not properly respond to thread interrupts
> ---------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-633
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-633
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpConn
>    Affects Versions: 3.1 Beta 1
>            Reporter: John Goodwin
>
> MultiThreadedHttpConnectionManager uses interrupts to notify waiting threads when a connection
is ready for them. Issues arise if the threads are interrupted by someone else while they
are still waiting on a thread, because doGetConnection does not remove the threads from the
queue of waiting threads when they are interrupted:
>                         connectionPool.wait(timeToWait);
>                         // we have not been interrupted so we need to remove ourselves
from the 
>                         // wait queue
>                         hostPool.waitingThreads.remove(waitingThread);              
         connectionPool.waitingThreads.remove(waitingThread);
>                     } catch (InterruptedException e) {
>                         // do nothing                    } finally {
>                         if (useTimeout) {
>                             endWait = System.currentTimeMillis();
>                             timeToWait -= (endWait - startWait);                    
   }                    }
> Under ordinary circumstances, the queue maintenance is done by the notifyWaitingThread
method. However, if the thread is interrupted by any other part of the system, it will (1)
not actually be released, since the loop in doGetConnection will force it back to the wait,
and (2) will be added the waiting thread to the queue repeatedly, which basically means that
the thread will eventually receive the interrupt from notifyWaitingThread at some later point,
when it is no longer actually waiting for a connection.
> This code could probably be re-architected to make it less error-prone, but the fundamental
issue seems to be the use of interrupts to signal waiting threads, as opposed to something
like a notify. 

-- 
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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message