Swapnil Bawaskar closed GEODE-4375.

> 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 20m
>  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

Reply via email to