[
https://issues.apache.org/jira/browse/POOL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831055#comment-13831055
]
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: https://issues.apache.org/jira/browse/POOL-240
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Dan McNulty
> Fix For: 2.0.1
>
> 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)
