Mailing-List: contact httpcomponents-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of mbecke@gmail.com designates
 64.233.162.238 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=KA8MDMBMYC4hbcj37fr0JwK+3zTmzeWCRiIkyEm0IhD2agbofWIzRuNQatM7gHiv1m6e3aOyUI2askiWq1FdqTENtmjxRMTGabE00Qu/Jcem90HTZMPgDYUeSNKQ3XBRayTpuvk3oUE3OceV2w3fTztTOcWdNGitn11UHcpudTM=
Message-ID: <78f7873e0702161204q1c3ab29fk1fffdfd6bac4ad0b@mail.gmail.com>
Date: Fri, 16 Feb 2007 12:04:47 -0800
From: "Michael Becke" <mbecke@gmail.com>
To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Subject: Re: [jira] Commented: (HTTPCLIENT-633)
 MultiThreadedHttpConnectionManager does not properly respond to thread
 interrupts
In-Reply-To: <29808119.1171642385937.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <27558544.1171470545753.JavaMail.jira@brutus>
	 <29808119.1171642385937.JavaMail.jira@brutus>

Agreed.  I think this is the best way to go for now.  I will create a
new patch with this change later tonight.

Mike

On 2/16/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_12473740 ]
>
> Roland Weber commented on HTTPCLIENT-633:
> -----------------------------------------
>
> Hi all,
>
> one more alternative, which Mike already mentioned on the dev list:
> (3) Re-throw InterruptedException as a RuntimeException, for example IllegalThreadStateException
>
> I'm also for re-throwing, and a RuntimeException would make sure that this doesn't trigger application code explicitly handling the ConnectionManagerTimeoutException exception. Yes it's an API change, but one that only affects the application in situations where MTHCM would be screwing up. Applications that work correctly now will work correctly despite the change, and applications that fail because of the RuntimeException will be better off than before, where they would fail in some unpredictable way because of the corrupted state in MTHCM.
>
> That we can't reliably tell whether there is an external InterruptedException or not can't be helped. If the thread was interrupted just after getting the connection, it would simply return with the connection and have it's interrupted flag set. I don't see a problem with keeping this behavior if two interruptions occur in quick succession.
>
> 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
> >
> >
> > 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