[
https://issues.apache.org/jira/browse/GEODE-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16341804#comment-16341804
]
Eric Shu commented on GEODE-4375:
---------------------------------
// In GEODE 1.4.0 and above case, shadowKeyFlag is always sent to
farside
// In GEODE 1.3.0 and below case, shadowKeyFlag is not sent and
presence or absence of
// shadowKey is judged according to the internal status
boolean readShadowKey = !isLoner;
if (Version.GEODE_140.compareTo(version) <= 0) {
readShadowKey = DataSerializer.readBoolean(in);
}
This change can break rolling upgrade. It could happen when a 1.3.0 server and
1.4.0 server co-exist in the cluster (rolling upgrade case). This could break
serialization as the boolean will not be sent from 1.3.0 server to 1.4.0
server, but the 1.4.0 server will try to read it. Instead, you can check
DatInput by using InternalDataSerializer.getVersionForDataStreamOrNull to
determine whether should read the boolean or not.
> Mismatch deserialization of TxCommitMessage
> -------------------------------------------
>
> Key: GEODE-4375
> URL: https://issues.apache.org/jira/browse/GEODE-4375
> Project: Geode
> Issue Type: Bug
> Components: serialization, transactions
> Reporter: Masaki Yamakawa
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am migrating from GemFire 7.x to Geode. After migration, An exception is
> now thrown in transaction commit. I would like to fix this problem.
> There are the following three patterns as a communication of a transaction.
> In this last pattern, a deserialization exception is thrown.
> * CacheServer (transaction) -> CacheServer
> * Client (transaction) -> CacheServer
> * CacheServer via Pool (transaction) -> CacheServer
> In toData of TxCommitMessage.RegionCommit.FarSideEntryOp it is decided
> whether or not to serialize ShadowKey depending on whether ClientVersion
> exists or not. In the case of the last pattern, it is serialized because
> ClientVersion exists. In fromData case, it decides whether or not to
> deserialize by whether it is a Loner or not. In the case of the last pattern,
> it is not Loner. As a result, a deserialization exception is thrown.
> Therefore, instead of judging by the internal status of each process, I'd
> like to send a flag as to whether ShadowKey exists or not.
> Note: The disadvantage is that bytes are increased slightly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
