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

2026-03-27 Thread Gary Gregory 
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  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...
>
> 
>
>
>
> 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
> 
> 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
>  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 i

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

2026-03-27 Thread ali takavci via dev 
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...


 |

 |

 |




On Friday, February 20, 2026 at 06:12:31 PM GMT+3, ali takavci 
 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

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 
 wrote:  
 
 On Fri, Feb 20, 2026 at 3:47 AM ali takavci via dev
 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.
>  |
>
>  |
>
>  |
>
>
>

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

2026-02-21 Thread ali takavci via dev 
 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 
 wrote:  
 
 On Fri, Feb 20, 2026 at 3:47 AM ali takavci via dev
 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.
>  |
>
>  |
>
>  |
>
>
>

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

2026-02-20 Thread Gary Gregory 
On Fri, Feb 20, 2026 at 3:47 AM ali takavci via dev
 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.
>  |
>
>  |
>
>  |
>
>
>

-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]