Hi Ali, Thank you for reaching out.
I hope we can find a solution that works for all. I'll have to read up on this over the weekend. Once we get something, I can cut a release candidate pretty much anytime. Feel free to provide a PR on GitHub. HTH, Gary On Fri, Mar 27, 2026, 10:38 ali takavci <[email protected]> wrote: > Hi Gary, > > Thanks again for your prompt response and for clarifying the baseline โ > agreed, we'll treat 2.13.0 as the starting point. > > I wanted to follow up to better understand your current thinking on this, > as we're approaching a decision point on our end. As Jedis maintainers, we > need to either proceed with a version bump using a workaround or hold off โ > and either path has downstream implications for our users. > Holding off indefinitely isn't really an option either, as we also provide > support for Spring Data Redis, and they have already decided to adopt the > newer commons-pool version and move forward. > > It would be really helpful to know: > - Whether there's already an approach in mind for addressing the > addObject() behavior in invalidateObject() > - Any rough sense of timeline, even if tentative > > To improve traceability and share our proposal more formally, I also filed > POOL-431 this week: > https://issues.apache.org/jira/browse/POOL-431 > > We're happy to contribute โ whether that's a patch, a design discussion, > or simply validating a proposed fix on the Jedis side. Just let us know how > we can best support/involve. > > Thanks again for your time. > > Best, > ali > > > > [POOL-431] invalidateObject() throws exception on pool replenishment fai... > > <https://issues.apache.org/jira/browse/POOL-431> > > > > On Friday, February 20, 2026 at 06:12:31 PM GMT+3, ali takavci < > [email protected]> wrote: > > > hey Gary, > > first of all, its so great to get a response back this quick. you are > doing such an amazing job there. > getting to the matter, you are right. i guess we just skip 2.13.0 and > attempt to bump from 2.12.1 to 2.13.1 > here ๐ Bump org.apache.commons:commons-pool2 from 2.12.1 to 2.13.1 by > dependabot[bot] ยท Pull Request #4409 ยท redis/jedis > <https://github.com/redis/jedis/pull/4409> > That change to invalidateObject incorporating addObject is obviously > there in 2.13.0, though I had overlooked it until you brought it to my > attention. > > thanks for taking time to look into it. let me know if there s anything i > can help with. > ali > > Bump org.apache.commons:commons-pool2 from 2.12.1 to 2.13.1 by dependabo... > > Bumps org.apache.commons:commons-pool2 from 2.12.1 to 2.13.1. You can > trigger a rebase of this PR by commenting... > <https://github.com/redis/jedis/pull/4409> > > > > On Friday, February 20, 2026 at 03:59:49 PM GMT+3, Gary Gregory < > [email protected]> wrote: > > > On Fri, Feb 20, 2026 at 3:47โฏAM ali takavci via dev > <[email protected]> wrote: > > > > Hi Commons Pool team, > > > > We are writing to flag a behavioral change in GenericObjectPool > introduced in version 2.13.1 that is causing a regression in our library. > > > > The change in question is:Ensure that invalidateObject replaces > destroyed instance. JIRA: POOL-424 ยท apache/commons-pool@32fd701 > > - ASF Jira > > > > As part of this fix, invalidateObject() now internally calls addObject() > to replace the destroyed instance. While we understand the intent, this > introduces a breaking change for consumers whose object factories are not > always capable of producing new pooled instances on demand โ for example, > factories that rely on external resources that may be temporarily > unavailable. > > Previously, upgrading from 2.12.1 to 2.13.1 exposed this issue: in > scenarios where the factory cannot provide a new instance, the addObject() > call fails, causing invalidateObject() to throw an exception. This breaks > our invalidation flow entirely. > > We are currently evaluating two workarounds โ either catching and > swallowing the exception from addObject(), or finding an alternative path > to destroy the object without triggering pool replenishment. Neither > approach is clean, and both carry trade-offs for our downstream users. > > > > We would like to raise the question of whether it would be feasible to > make the addObject() call within invalidateObject() optional โ for > instance, controlled by a configuration flag โ so that pools backed by > fallible factories are not adversely impacted. > > We are happy to contribute a patch or participate in the design > discussion if that would be helpful. > > > > Thank you for your time and for maintaining this library.ali takavci > > Hello Ali, > > Thank you for your report. > > POOL-424 was fixed in 2.13.0, not 2.13.1. Are you sure your issue > started with 2.13.1 and not 2.13.0? > > I want to make sure we get the baseline right. > > Thank you. > Gary > > > > > > > > > > | > > | > > | | > > - ASF Jira > > > > > > | > > > > | > > > > | > > > > > > > > > > > > | > > | > > | > > | | | > > > > | > > > > | > > | > > | | > > Ensure that invalidateObject replaces destroyed instance. JIRA: > POOL-424... > > > > Apache Commons Pool. Contribute to apache/commons-pool development by > creating an account on GitHub. > > | > > > > | > > > > | > > > > > > >
