> On Nov 23, 2018, at 10:51 AM, Phil Steitz <phil.ste...@gmail.com> wrote:
>
> On 11/23/18 2:57 AM, Mark Struberg wrote:
>> should read: This change (putting a new item back to the idle pool) was
>> needed to prevent a dead-lock....
>>
>> *grabbing a fresh coffee* le
>
> I am sorry I did not look carefully enough at this issue before reviewing the
> change. After reviewing the DBCP ticket (OP likely unrelated, IMO), I think
> that the right answer here is WONT_FIX. That sounds harsh, but it seems to me
> that the obvious solution here is for the user to set maxIdle to at least 1.
> What the fix does is effectively that, without changing the setting. If
> waiting threads die or time out while the create is happening, there will be
> an idle instance in the pool and for certain one is being put there on the
> way to getting checked back out. See comments on POOL-327.
>
> If the consensus is to insert this workaround to enable the pool to retain
> liveness in the use case, it's probably best to use ensureIdle(1, false) (see
> POOL-240). It could be that just moving the call to ensureIdle inside
> destroy would be OK. But as stated above, this breaks the maxIdle contract.
>
> I see that your original report / use case here is from DBCP, Mark. Was it
> prepared statements or connections that you were trying to limit to 0 idle?
> Is there a reason that just using 1 would not work?
Ok holding off on RC3 then from master. Right?
-Rob
>
> Phil
>
>
>>
>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg <strub...@yahoo.de>:
>>>
>>> This change (putting a new item back to the idle pool was needed to prevent
>>> a dead-pool
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>> .
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
