[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
