[
https://issues.apache.org/jira/browse/POOL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13828310#comment-13828310
]
Mark Thomas commented on POOL-240:
----------------------------------
I agree that this is a bug. I've taken a quick look at how this might be fixed
in GOP. My current thoughts are to extract the majority of the ensureMinIdle()
code to a separate method that takes a parameter of how many idle objects to
ensure and then call that new method with a parameter of 1 when an object is
destroyed because it failed validation / passivation on return. It looks like
GKOP will be able to just call addObject(K) in the same situation.
I'm busy fixing some WebSocket issues over in Tomcat land at the moment so I'm
unlikely to get to this in the next few days. This is next on my TODO list
after that, but if someone beats me to it I'm not going to complain.
> 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)
