[
https://issues.apache.org/jira/browse/HTTPCLIENT-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473728
]
John Goodwin commented on HTTPCLIENT-633:
-----------------------------------------
Hi Michael,
I appreciate the quick response and follow-up. In the longer term, I, at least,
would lobby for a re-throw of the interrupt. My application is a high-load,
highly concurrent system, where we need the ability to interrupt threads if
they have been working too long. (NB: a HUGE help to us would be an HttpClient
that uses NIO, but I realize that's pretty out there.)
I agree, however, that the FIFO feature is quite desireable. You could use a
fair lock, but that obviously has negative performance side-effects (perhaps
FIFO could be optional?), and is another component that would have to be built
from scratch unless you mandate Java 5.0+.
Thanks,
John
> 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]
