Bug 1180680
| Summary: | Transaction from new topology rolled back (but succeeds on originator) | |||
|---|---|---|---|---|
| Product: | [JBoss] JBoss Data Grid 6 | Reporter: | Radim Vansa <rvansa> | |
| Component: | Infinispan | Assignee: | Tristan Tarrant <ttarrant> | |
| Status: | ASSIGNED --- | QA Contact: | Martin Gencur <mgencur> | |
| Severity: | high | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 6.4.0 | CC: | chuffman, jdg-bugs, jpallich, ttarrant | |
| Target Milestone: | DR1 | |||
| Target Release: | 6.5.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: |
In Red Hat JBoss Data Grid, after network partition (split-brain) is resolved, nodes start reconnecting through a series of merge events. In some of these merges a node may be reported to temporarily leave the cluster; if such node is executing a transaction spanning other nodes, this transaction is not executed on the remote node. However, the transaction can be confirmed and succeeds on the originating node.
The result is stale value on the node not committing this transaction. This inconsistency is not resolved until the entry is updated or removed; reads can return both stale and committed value.
After the merge is finished on all nodes, this situation cannot happen any more.
There is no workaround for this issue.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1184285 (view as bug list) | Environment: | ||
| Last Closed: | Type: | Bug | ||
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1153111, 1184285 | |||
|
Description
Radim Vansa
2015-01-09 16:50:01 UTC
Dan Berindei <dberinde> updated the status of jira ISPN-5137 to Coding In Progress Failing QA, there is a very similar issue causing the transactions to be not executed on some of the nodes. Integrated also to 6.4.x branch. Thanks for confirming that. Found another issue with originator successfully commiting transaction, while other participating nodes rollbacked it. From client perspective, this leads to unexpected return values. Dan Berindei <dberinde> updated the status of jira ISPN-5274 to Coding In Progress Dan Berindei <dberinde> updated the status of jira ISPN-5274 to Reopened |