commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <>
Subject [jira] Commented: (POOL-162) When waiting threads are interrupted, pool can leak capacity
Date Thu, 18 Mar 2010 03:38:27 GMT


Phil Steitz commented on POOL-162:

Thanks, Mark!

Gave me a headache, but the test and fix look good, modulo one comment. With your patch, if
the latch has been served when the thread is interrupted, we do not propagate the interrupt,
but let the thread continue and get served. This seems reasonable for most use cases. The
alternative would be to handle mayCreate and pair != null separately, in the second case destroying
the object and in both cases removing the latch from the queue and setting thread interrupt
status. If the interrupt is to shorten or end the wait, the patch impl is probably best. If
for another reason, the client might rather propagate the exception and not use pool capacity.
I can't t think of realistic use cases where the second would be the case, so unless someone
else can, I am +1 on resolving this based on the fix in r924479

> When waiting threads are interrupted, pool can leak capacity
> ------------------------------------------------------------
>                 Key: POOL-162
>                 URL:
>             Project: Commons Pool
>          Issue Type: Bug
>    Affects Versions: 1.5, 1.5.1, 1.5.2, 1.5.3, 1.5.4
>            Reporter: Phil Steitz
> As reported on commons-dev (, when waiting
threads are interrupted, GOP, GKOP may leak capacity.   I do not yet have a test case to confirm
this, but I suspect that the problem reported by the user is caused by a missing  _allocationQueue.remove(latch)
before rethrowing InterruptedException in borrowObject.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message