Re: [POOL] - Behavioral Change in GenericObjectPool.invalidateObject() Since 2.13.1 (POOL-424)

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