[
https://issues.apache.org/jira/browse/HTTPCLIENT-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473732
]
John Goodwin commented on HTTPCLIENT-633:
-----------------------------------------
I would vote against option 1. The connection manager has a shutdown method if
that is the desired result. Interrupting a single thread might be done simple
for throughput maintenance.
> 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
> Attachments: mthcm-interruption.patch
>
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
