hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Becke" <mbe...@gmail.com>
Subject Re: [jira] Commented: (HTTPCLIENT-633) MultiThreadedHttpConnectionManager does not properly respond to thread interrupts
Date Sat, 17 Feb 2007 23:10:49 GMT
Access to this variable is synchronized so volatile shouldn't be
required, right?

Mike

On 2/17/07, Roland Weber (JIRA) <jira@apache.org> 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message