[
https://issues.apache.org/jira/browse/HTTPCLIENT-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473731
]
Oleg Kalnichevski commented on HTTPCLIENT-633:
----------------------------------------------
Hi Mike,
I think this is as good as it gets for HttpClient 3.1. As far as
InterruptedException caused by an external interrupt is concerned we can't
simply re-throw it. I see two options here. Both are quite ugly, so alternative
ideas are very welcome
(1) Quietly shutdown the connection manager. At the end of day this is likely
to be the main reason for interrupting the connection manager's thread in the
first place.
(2) Re-throw InterruptedException as an exception derived from
ConnectionPoolTimeoutException (yes, I know)
Oleg
> 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]
