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