[
https://issues.apache.org/jira/browse/POOL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831031#comment-13831031
]
Phil Steitz commented on POOL-240:
----------------------------------
I committed Dan's test case (thanks!) disabled in r1545063. I also committed
(disabled, failing) tests for both invalidateObject and validation failures on
return for GOP in r1544948. In r1544942, I added similar tests for GOP in the
1.5 branch, demonstrating that this bug is not present in 1.x (at least for
GOP, but GKOP should be the same).
> GKOP: invalidateObject does not unblock threads waiting in borrowObject
> -----------------------------------------------------------------------
>
> Key: POOL-240
> URL: https://issues.apache.org/jira/browse/POOL-240
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Dan McNulty
> Attachments: InvalidateObjectTest.java
>
>
> 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
(v6.1#6144)
