You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Bruce Schuchardt (JIRA)" <ji...@apache.org> on 2018/02/05 17:33:00 UTC
[jira] [Commented] (GEODE-4375) Mismatch deserialization of
TxCommitMessage
[ https://issues.apache.org/jira/browse/GEODE-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16352673#comment-16352673 ]
Bruce Schuchardt commented on GEODE-4375:
-----------------------------------------
commit b1442647308f4a07d5bd9354462cae64d9fdeed8 (HEAD -> develop)
Author: Bruce Schuchardt <bs...@pivotal.io>
Date: Mon Feb 5 09:00:31 2018 -0800
GEODE-4375: Fix problem that an exception occurs when transaction from CacheServer via Pool (#1363)
Modifying the test for proper backward-compatibility testing. The test was modifying a client to pretend to be running v1.3 but it was actually using Version.CURRENT code on the branch running the test. This caused an OOME when the client/server handshake was modified.
> 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
> Fix For: 1.5.0
>
> Time Spent: 1h 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)