hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roland Weber (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-677) Connection pool uses Thread.interrupt()
Date Mon, 17 Dec 2007 13:21:43 GMT

    [ 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


Mime
View raw message