You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "xiaojian zhou (JIRA)" <ji...@apache.org> on 2018/09/25 17:31:00 UTC
[jira] [Resolved] (GEODE-4886) Add test to
WANRollingUpgradeDUnitTest to detect serialization changes to
GatewaySenderEventImpl
[ https://issues.apache.org/jira/browse/GEODE-4886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
xiaojian zhou resolved GEODE-4886.
----------------------------------
Resolution: Won't Fix
Since GEODE-4834 has revoked the newly added
isConcurrencyConflict field. There's no more serialization changes.
> Add test to WANRollingUpgradeDUnitTest to detect serialization changes to GatewaySenderEventImpl
> ------------------------------------------------------------------------------------------------
>
> Key: GEODE-4886
> URL: https://issues.apache.org/jira/browse/GEODE-4886
> Project: Geode
> Issue Type: Bug
> Components: wan
> Reporter: nabarun
> Priority: Major
>
> GatewaySenderEventImpl types are added to the queue. When rolling upgrade occurs, these events are gii'd/distributed as region data/ not as messages. That means the toData_version and fromData_version code does not get executed.
> We should have a test (or two) in WANRollingUpgradeDUnitTest that can detect this scenario.
> I believe the scenario is trying to get a new sender to deserialize an old event:
> 1.create a sender, pause
> 2.do puts, build up the queue.
> 3. roll to current
> 4.start senders on current
> The second scenario is to get new events to flow back to the old member and have the old member try to deserialize the new event
> 1.)create a sender, pause
> 2.)do puts, build up the queue.
> 3.) roll to current
> 4.) do additional puts that get queued in the new member with a redundant copy on the old member
> 5.) remove the new member
> 6.) start sender on old member
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)