On Fri, Nov 23, 2018 at 11:51 AM Rob Tompkins <chtom...@gmail.com> wrote:
> > > > 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? > 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 <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 > >
