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
