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

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



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

 |

 |