commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <>
Subject [jira] [Commented] (POOL-240) GKOP: invalidateObject does not unblock threads waiting in borrowObject
Date Sun, 24 Nov 2013 21:13:35 GMT


Phil Steitz commented on POOL-240:

I can think of two, both pretty ugly, workarounds for this issue until we get 2.0.1 with a
fix out.

1.  For the specific issue in the report (invaliateObject not freeing capacity), follow invalidateObject
with a borrow-return sequence.  The borrow will be allowed to create a new object and the
return will make it available to waiting threads.  
2.  Enable the evictor (set timeBetweenEvictionRuns to a positive value) and set minIdle to
1.  This will handle both the invalidateObject and failed validation on return cases.  Unfortunately,
relief for blocked threads will only come when the evictor runs.

> GKOP: invalidateObject does not unblock threads waiting in borrowObject
> -----------------------------------------------------------------------
>                 Key: POOL-240
>                 URL:
>             Project: Commons Pool
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Dan McNulty
>             Fix For: 2.0.1
>         Attachments:
> It appears that when threads are blocked in GKOP.borrowObject due to max object limits
being reached and another thread calls invalidateObject, the threads blocked in GKOP.borrowObject
are not woken up to attempt to create a new object.
> Have the semantics changed for invalidate in 2.0?
> Attached is a unit test that demonstrates this issue. I should note that this test passed
against POOL 1.5, after making the appropriate changes due to the API changes in 2.0.
> After a cursory glance through the source for GenericObjectPool, it looks like it might
be affected by the same issue.

This message was sent by Atlassian JIRA

View raw message