Sorry I got busy. I will they to get final changes in tomorrow or convince myself it is ok to release without them. Apologies for the delay
> On Sep 9, 2023, at 6:41 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > Hi Phil, > > Where are we on a 2.12.0 release candidate? > > Gary > >> On Mon, Jul 31, 2023 at 10:33 PM Phil Steitz <phil.ste...@gmail.com> wrote: >> >> OK, I found the source of the performance hit. In the POOL-411 changes, we >> had inadvertently forced every register to acquire a write lock from the >> keylock. I think I also finally definitively fixed the root issue there. >> The tricky bit about the numInterested tracking is that the counters are >> attached to the ObjectDeques, which can be replaced. If this happens while >> waiting for a write lock in either register or deregister, the code can end >> up updating the counter on a pool that has been replaced. I added checks >> to trap deregistration of a null pool (should never happen) and followed >> Sebb's suggestion to add a check for numInterested going negative. The >> accounting setup is very efficient, but tricky to maintain. For 3.0, we >> might consider moving numInterested tracking to a hashmap. For 2.x, I >> think the setup is fixed now and performance is the same as earlier >> versions. Soak tests look good. >> >> One last thing I would like to do before we cut 2.12.0: >> >> We are going to be making incompatible changes in 3.0 and I don't think we >> need to telegraph all of the API changes via deprecations in 2.x - most >> notably the recent method name changes of the form s/Time/Duration. I >> understand the rationale for these changes, but they make the 2.x code very >> messy with double deprecations - first from the "millis" methods and then >> from "Time" to "Duration." I think it would be better to keep the existing >> deprecations for the "millis" methods, but drop the new "Duration" ones and >> remove deprecations for the ones they replace. I can see the argument that >> it is better to tell users now, but that takes away flexibility in 3.0 and >> makes the API look very confusing with so many methods that do the same >> thing. Any objections ? >> >> Phil >> >>> On Sat, Jul 29, 2023 at 3:59 PM Phil Steitz <phil.ste...@gmail.com> wrote: >>> >>> I have run my first round of soak and performance tests on what is now in >>> the 2.x branch. Good news is the code looks stable. Not so good news is >>> it appears that GKOP performance has taken a material hit vs 2.11 and >>> earlier versions. I need to confirm this via more targeted tests and if it >>> turns out not to be real, figure out what is causing it. Hopefully I will >>> get to this done in the next few days. >>> >>> Phil >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
