While changing a void method to have a return type does not break source
compatibility, it appears likely to break binary compatibility[1].
So, if you are compiling your client from source, it will compile successfully
against either Geode 1.12 or Geode 1.13. But if your client was already
Remember, if there are any concerns about recent backwards-compatible
changes to Geode user APIs, they should be brought on the dev list.
Also, backward-compatible changes are by definition safe and ok for a user
API because it won't break the user's code.
Here's an example of a user API that I
There appears to be consensus that this is a critical fix.
The following commit has been brought into release/1.12 as the
critical fix for GEODE-7814:
git cherry-pick -x db86faec699aca67c02325bca22dcd5b913ddfed
GEODE-7814 has been marked as 'resolved in' 1.12.
Regards
EB
On Thu, Feb 27, 2020
Bruce - The primary gist of it is, client applications do not use the
preconfigured classpath determined by Geode itself, such as would be the
case when you start servers using *Gfsh*. Clients are not started with
*Gfsh*, or any other Geode script for that matter.
On Thu, Feb 27, 2020 at 8:53 AM
@Bruce, Thank you for bringing this up. The first iteration of this
would specifically target only the server-side. BUT, I do agree, that
clients could suffer similar problems. Yet, from experience, I (and many
other users) have deployed different versions of the Spring Framework
(compared to
Udo, how does this relate to the client cache? I assume people have the same
problems with dependencies in client-cache applications that they have in
functions that they deploy on a server-cache.
On 2/26/20, 10:10 AM, "Udo Kohlmeyer" wrote:
Hi there Geode Dev's.
There is a new
+1
The change Juan has made corrects a problem introduced during membership
refactoring. Every cache operation message that's sent allocates several
objects that used to be held in statics but were moved into instance variables
at one point. Juan's change moves these back into static
+1
On Thu, Feb 27, 2020, 06:43 Owen Nichols wrote:
> +1
>
> On Thu, Feb 27, 2020 at 1:49 AM Ju@N wrote:
>
> > Hello devs,
> >
> > I'd like to include the fix for GEODE-7814 [1] in release 1.12.0.
> > The change prevents a huge amount of unnecessary allocation of objects
> > while
+1
On Thu, Feb 27, 2020 at 1:49 AM Ju@N wrote:
> Hello devs,
>
> I'd like to include the fix for GEODE-7814 [1] in release 1.12.0.
> The change prevents a huge amount of unnecessary allocation of objects
> while sending/receiving messages, improving the overall performance.
> The SHA is
Forwarding message that was initially sent to u...@geode.apache.org.
-- Forwarded message --
From: *aashish choudhary*
Date: Thursday, February 27, 2020
Subject: Function execute method thread safety
To: u...@geode.apache.org
No-one?
We ended up synchronising execute method
Hello devs,
I'd like to include the fix for GEODE-7814 [1] in release 1.12.0.
The change prevents a huge amount of unnecessary allocation of objects
while sending/receiving messages, improving the overall performance.
The SHA is db86faec699aca67c02325bca22dcd5b913ddfed [2].
Best regards.
[1]:
11 matches
Mail list logo
