You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Bruce Schuchardt <br...@vmware.com> on 2020/07/09 15:00:39 UTC
[PROPOSAL] backport fix for GEODE-8020 to support/1.13
There are reports that SSL performance is off on the support/1.13 branch with respect to the support/1.12 branch, but performance on develop okay. The only communications changes in develop that aren’t in 1.13 are those that fixed this long-standing bug, so I’d like to backport it to the 1.13 branch.
https://github.com/apache/geode/pull/5048
The error was in the cluster communications message-streamer class that created some extra objects during message transmission. The fix is small and has been, at this point, through many test iterations.
RE: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
Posted by Alberto Bustamante Reyes <al...@est.tech>.
+1
________________________________
De: Donal Evans <do...@vmware.com>
Enviado: jueves, 9 de julio de 2020 17:50
Para: dev@geode.apache.org <de...@geode.apache.org>
Asunto: Re: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
+1
________________________________
From: Bruce Schuchardt <br...@vmware.com>
Sent: Thursday, July 9, 2020 8:00 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
There are reports that SSL performance is off on the support/1.13 branch with respect to the support/1.12 branch, but performance on develop okay. The only communications changes in develop that aren’t in 1.13 are those that fixed this long-standing bug, so I’d like to backport it to the 1.13 branch.
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5048&data=02%7C01%7Cdoevans%40vmware.com%7C2fb1536164944cdb5c2808d82418dc26%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637299036483136624&sdata=u5UoE8C7bJdwc7RohfFCE1T%2FnbD%2FWGF7Cg%2F%2Fk9lIIA4%3D&reserved=0
The error was in the cluster communications message-streamer class that created some extra objects during message transmission. The fix is small and has been, at this point, through many test iterations.
Re: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
Posted by Donal Evans <do...@vmware.com>.
+1
________________________________
From: Bruce Schuchardt <br...@vmware.com>
Sent: Thursday, July 9, 2020 8:00 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
There are reports that SSL performance is off on the support/1.13 branch with respect to the support/1.12 branch, but performance on develop okay. The only communications changes in develop that aren’t in 1.13 are those that fixed this long-standing bug, so I’d like to backport it to the 1.13 branch.
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5048&data=02%7C01%7Cdoevans%40vmware.com%7C2fb1536164944cdb5c2808d82418dc26%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637299036483136624&sdata=u5UoE8C7bJdwc7RohfFCE1T%2FnbD%2FWGF7Cg%2F%2Fk9lIIA4%3D&reserved=0
The error was in the cluster communications message-streamer class that created some extra objects during message transmission. The fix is small and has been, at this point, through many test iterations.
Re: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
Posted by Dave Barnes <db...@apache.org>.
Thanks, Bruce.
On Thu, Jul 9, 2020 at 10:32 AM Bruce Schuchardt <br...@vmware.com> wrote:
> Since I had 3 +1’s I merged the change to support/1.13
>
> From: Bruce Schuchardt <br...@vmware.com>
> Date: Thursday, July 9, 2020 at 8:00 AM
> To: "dev@geode.apache.org" <de...@geode.apache.org>
> Subject: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
>
> There are reports that SSL performance is off on the support/1.13 branch
> with respect to the support/1.12 branch, but performance on develop okay.
> The only communications changes in develop that aren’t in 1.13 are those
> that fixed this long-standing bug, so I’d like to backport it to the 1.13
> branch.
>
> https://github.com/apache/geode/pull/5048
>
> The error was in the cluster communications message-streamer class that
> created some extra objects during message transmission. The fix is small
> and has been, at this point, through many test iterations.
>
Re: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
Posted by Bruce Schuchardt <br...@vmware.com>.
Since I had 3 +1’s I merged the change to support/1.13
From: Bruce Schuchardt <br...@vmware.com>
Date: Thursday, July 9, 2020 at 8:00 AM
To: "dev@geode.apache.org" <de...@geode.apache.org>
Subject: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
There are reports that SSL performance is off on the support/1.13 branch with respect to the support/1.12 branch, but performance on develop okay. The only communications changes in develop that aren’t in 1.13 are those that fixed this long-standing bug, so I’d like to backport it to the 1.13 branch.
https://github.com/apache/geode/pull/5048
The error was in the cluster communications message-streamer class that created some extra objects during message transmission. The fix is small and has been, at this point, through many test iterations.
Re: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
Posted by Alexander Murmann <am...@apache.org>.
While it's really late in the branch lifecycle and we should have shipped a
month ago, performance degradations are a no-go
+!
On Thu, Jul 9, 2020 at 8:00 AM Bruce Schuchardt <br...@vmware.com> wrote:
> There are reports that SSL performance is off on the support/1.13 branch
> with respect to the support/1.12 branch, but performance on develop okay.
> The only communications changes in develop that aren’t in 1.13 are those
> that fixed this long-standing bug, so I’d like to backport it to the 1.13
> branch.
>
> https://github.com/apache/geode/pull/5048
>
> The error was in the cluster communications message-streamer class that
> created some extra objects during message transmission. The fix is small
> and has been, at this point, through many test iterations.
>