You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Roland Weber (JIRA)" <ji...@apache.org> on 2007/12/17 14:21:43 UTC

[jira] Commented: (HTTPCLIENT-677) Connection pool uses Thread.interrupt()

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552401 ] 

Roland Weber commented on HTTPCLIENT-677:
-----------------------------------------

This is a nasty one. Currently, all synchronization is done on the pool level to protect access to the various queues. Threads wait() on the pool, thereby releasing the lock while they wait. There are no notifications, instead the chosen threads are interrupted.

To avoid the interrupt, threads have to wait on distinct objects, at least one per route queue, better one per thread. To wait on those objects, a thread needs to synchronize on the object. During the wait, only the lock on the extra object will be released, but not the lock on the pool. The following sequence is necessary to make this work:
- create thread specific object
- acquire lock on the pool
- update queues
- release lock on the pool (*)
- acquire lock on the object (*)
- call wait() on the object (*)
- release lock on the object (?)
- acquire a new lock on the pool (?)
- update queues
- release lock on the pool
The obvious weak spot (*) is the time between releasing the first lock on the queue and calling wait() on the object. The wakeup notification from another thread may be triggered inbetween and must not be lost. Therefore, the object needs to remember a notification until a thread comes to wait.
A second potential weak spot (?) is the time from wakeup until the lock on the pool is re-acquired. A thread might be chosen for notification a second time in this timeframe. Either the object must carry an indicator that it has already been chosen, or the first notifier must remove the object from the queues before notification. In the second case, the thread has to reacquire the pool lock and to update the queues only if it is interrupted externally rather than being notified. Which still leaves a window for notification to the interrupted thread. 

I know how to deal with (*), but I need a bit more time to think about (?).

yuck.


> Connection pool uses Thread.interrupt()
> ---------------------------------------
>
>                 Key: HTTPCLIENT-677
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-677
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpConn
>    Affects Versions: 4.0 Alpha 1, 4.0 Alpha 2
>            Reporter: Roland Weber
>            Assignee: Roland Weber
>             Fix For: 4.0 Alpha 3
>
>
> The connection pool for TSCCM uses Thread.interrupt() to wake up waiting threads.
> This interferes with application interrupts.
> - expose InterruptedException in interface
> - change pool implementation to use wait/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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org