Access to this variable is synchronized so volatile shouldn't be
required, right?
Mike
On 2/17/07, Roland Weber (JIRA) <[EMAIL PROTECTED]> wrote:
[
https://issues.apache.org/jira/browse/HTTPCLIENT-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473940
]
Roland Weber commented on HTTPCLIENT-633:
-----------------------------------------
Hi Mike,
please declare the 'interruptedByConnectionPool' attribute volatile. Otherwise,
it looks like a straightforward fix for the problem.
cheers,
Roland
> 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, 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
