osdir.com

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

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


On Fri, Nov 23, 2018 at 11:51 AM Rob Tompkins <chtompki@xxxxxxxxx> wrote:

>
>
> > On Nov 23, 2018, at 10:51 AM, Phil Steitz <phil.steitz@xxxxxxxxx> 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?
>

I would think that we at least need to documentation added to the code
someplace to help future maintainers.

Are there code changes coming?

Gary

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