osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1


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.steitz@xxxxxxxxx>:
> 
> 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 <struberg@xxxxxxxx>:
>>> 
>>> This change (putting a new item back to the idle pool was needed to prevent a dead-pool
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>>> 
>>> .
>>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx