[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
