Bug 1310610

Summary: Support update operation during rolling upgrade and avoid data inconsistency between source cluster and target cluster
Product: [JBoss] JBoss Data Grid 6 Reporter: Masafumi Miura <mmiura>
Component: unspecifiedAssignee: Tristan Tarrant <ttarrant>
Status: NEW --- QA Contact: Martin Gencur <mgencur>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.5.1, 6.6.0CC: afield, jdg-bugs, wfink
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Masafumi Miura 2016-02-22 10:59:38 UTC 
### Description of problem:

Current implementation does not support update operation during rolling upgrade and it cause data inconsistency. Please add a feature to support for update operation during rolling upgrade and avoid data inconsistency between source cluster and target cluster


### How reproducible:

Anytime when update operation occurred on both source cluster and target cluster during rolling upgrade.


### Steps to Reproduce:

1. Configure JDG as noted in https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Data_Grid/6.6/html/Developer_Guide/chap-Rolling_Upgrades.html then start new Target Cluster
2. Configure clients to point to the Target Cluster, and one by one,
restart each client node
   At this moment:
    - ClientA remained pointing to the Source Cluster
    - ClientB changed to point to the Target Cluster
3. ClientA get(KEY1), then VALUE1 was returned from the Source Cluster
4. ClientB get(KEY1), then VALUE1 was returned from the Target Cluster
5. ClientA put(KEY1,VALUE2) to the Source Cluster
6. ClientA get(KEY1), then **VALUE2** was returned from the Source Cluster
7. ClientB get(KEY1), then **VALUE1** was returned from the Target Cluster


### Actual results:

Update operation on the Source Cluster does not propagate to the
Target Cluster. The two clusters return different values.


### Expected results:

Update operation on the Source Cluster propagates to the
Target Cluster. The two clusters return same value.