[infinispan-issues] [JBoss JIRA] (ISPN-8903) Conflict resolution not initiated if node rejoins with same topology
Dan Berindei (JIRA)
issues at jboss.org
Tue Apr 3 09:46:01 EDT 2018
[ https://issues.jboss.org/browse/ISPN-8903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13555064#comment-13555064 ]
Dan Berindei commented on ISPN-8903:
------------------------------------
A couldn't update any entries, because it still uses a cache topology where B co-owns all the segments, and even if accessible B would have rejected the updates because of the lower topology id. In my view that means no conflict, and no reason to run the merge policy.
> Conflict resolution not initiated if node rejoins with same topology
> --------------------------------------------------------------------
>
> Key: ISPN-8903
> URL: https://issues.jboss.org/browse/ISPN-8903
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.2.1.Final, 9.3.0.Final
>
>
> The current logic in PreferAvailabilityStrategy and PreferConsistencyStrategy assumes that when a split brain occurs, the two partitions will continue to operate independently before a merge occurs.
> Consider a cluster \{A,B\} which partitions into P1 \{A\} and P2 \{B\}. P1 continues to operate and update cache entries, however P2 makes no progress (possibly down to a long GC pause). When P2 merges into P1, no conflict resolution occurs as the maxTopology contains all of the possible owners. Conflict resolution should be attempted in this scenario, as it's possible that entries have been put to P1 during the partition and therefore P2 will have stale values.
> This can be reproduced by creating two nodes, pausing one process, wait for split and then resuming the process. No CR will occur.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
More information about the infinispan-issues
mailing list