[
https://issues.apache.org/jira/browse/POOL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13827853#comment-13827853
]
Phil Steitz commented on POOL-240:
----------------------------------
Thanks for reporting this. This looks like a bug. Unless I am missing
something, looks like validation failures on return (both GOP / GKOP) will
behave similarly - blocked threads waiting on depleted pool will stay blocked.
The change in behavior is due to move away from wait/notify setup in pool 1.x.
I suspect what is going to be needed is a call to create() added to destroy()
or some kind of notification engineered into the queue.
> 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)
