Hi Phil!

>  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.

I thought about that as well!
Setting maxIdle to 1 will make it less likely but a deadlock will STILL happen.

So I fear we really need to tackle this. Stackoverflow and our own bug tracker 
is full of such reports :(

LieGrue,
strub


> Am 23.11.2018 um 16:51 schrieb Phil Steitz <phil.ste...@gmail.com>:
> 
> 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?
> 
> 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

Reply via email to