It's all good Phil :-) I'm glad you took the time to look things over.
Gary
On Sun, Sep 10, 2023, 5:18 PM Phil Steitz wrote:
> Well, now I really do need to apologize. I looked carefully again at the
> japicmp report and now agree that it is best to leave things as they are.
> I don't think it
Well, now I really do need to apologize. I looked carefully again at the
japicmp report and now agree that it is best to leave things as they are.
I don't think it is likely we will change the names again and this is what
deprecations are for. So as far as I am concerned, things are good to go.
I
Thanks for the update, no need to apologize :-)
Gary
On Sat, Sep 9, 2023, 6:31 PM Phil Steitz wrote:
> 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
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 wrote:
>
> Hi Phil,
>
> Where are we on a 2.12.0 release candidate?
>
> Gary
>
>> On Mon, Jul 31, 2023 at
Hi Phil,
Where are we on a 2.12.0 release candidate?
Gary
On Mon, Jul 31, 2023 at 10:33 PM Phil Steitz 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 fin
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
att
Sounds good.
Gary
On Sat, Jul 29, 2023 at 7:00 PM Phil Steitz 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
>
