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