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 Wed, 14 Feb 2007 22:55:05 GMT

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

Michael Becke commented on HTTPCLIENT-633:

Hi John,

I would agree, using object notification is probably a cleaner way to do this.  I'm not sure
why I did it this way originally, simplicity perhaps.  My question is if interrupting a waiting
thread outside of the connection manager is something we want to support.  If we did, would
we just throw a ConnectionPoolTimeoutException when it occurs?   This would seem to break
the contract of doGetConnection.  I'm not sure how we will handle HttpConnection getConnection(HostConfiguration
hostConfiguration) without an API change.

Assuming we did want to change this, we would need to wait on the HostConnectionPool instead
of the ConnectionPool.  Doing this brings up a couple of potential issues, but I think they're
all fixable.  In particular:

 - We would have two layers of synchronization to go through, ConnectionPool and HostConnectionPool,
and would need to handle this carefully to avoid potential dead-locks, race conditions, etc.
 - We lose the FIFO nature currently guaranteed to waiting threads.  Object.notify() makes
no guarantees about which thread will be woken first.

To get this into 3.1 we will definitely want to have an RC release with this change first.
 Given the complexity of synchronization I would want to give it some time for testing.

Any other thoughts?


> 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);              
>                     } 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

View raw message