+1
On Tue, May 19, 2020 at 10:05 AM Udo Kohlmeyer wrote:
> +1
> On May 19, 2020, 8:53 AM -0700, Bruce Schuchardt ,
> wrote:
> While investigating a distributed hang we discovered that the alerting
> system was blocking the logging of critical information that would have
> helped diagnose the iss
This is to update documentation to better explain the Cluster management
service and various geode/system properties that control the behavior of
it. It also provides more usage examples in the documentation. There is no
product code change in this, but tt would be helpful to the users who would
li
+1
On May 19, 2020, 8:53 AM -0700, Bruce Schuchardt ,
wrote:
While investigating a distributed hang we discovered that the alerting system
was blocking the logging of critical information that would have helped
diagnose the issue. This PR modifies the logging of this information to first
log i
While investigating a distributed hang we discovered that the alerting system
was blocking the logging of critical information that would have helped
diagnose the issue. This PR modifies the logging of this information to first
log it at “info” level and then at “fatal” level so that in the fut
While GatewaySenderEventImpl is structured correctly to fit into the
backward-compatibility serialization framework it does have some odd code. It
looks like mistakes were made in the past in the serialization code for this
class and the odd code is trying to compensate.
The "version" variable
I misunderstood the question, sorry about that.
I'm not entirely familiar with the serialization versioning mechanism, so
I'll leave somebody else with deeper knowledge to answer.
Cheers.
On Tue, 19 May 2020 at 14:30, Alberto Gomez wrote:
> Hi Juan,
>
> Thanks for your answer.
>
> According to
Hi Juan,
Thanks for your answer.
According to
https://cwiki.apache.org/confluence/display/GEODE/Managing+Backward+Compatibility
there are two ways to manage backward compatibility for classes that implement
SerializationVersions.
Either implementing `toDataPre/fromDataPre` methods that Data S
Hi Juan Jose,
I think Alberto is asking about how the check is done, not about why its done.
The method he is asking about is mixing the two ways we know for handling
backward compatibility.
One is creating the "toDataPre_GEODE_X_X_X" and "fromDataPre_GEODE_X_X_X"
methods. And the other one is
Hello Alberto,
It looks like the property *isConcurrencyConflict* was added as part of
*GEODE-3967* [1] and this was released as part of Geode 1.9.0; that seems
to the reason why the check is in place: if we get an instance of
*GatewaySenderEventImpl* from a member running a version higher than 1.
Hi,
Looking at the fromData method of GatewaySenderEventImpl I see that it contains
a conditional reading of the isConcurrencyConflict when version is greater than
Geode 1.9.0 one. See below:
@Override
public void fromData(DataInput in,
DeserializationContext context) throws IOExcepti
10 matches
Mail list logo
