[infinispan-issues] [JBoss JIRA] (ISPN-8903) Conflict resolution not initiated if node rejoins with same topology

[Ryan Emerson (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-8903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13554830#comment-13554830 ] 

Ryan Emerson commented on ISPN-8903:
------------------------------------

[~dan.berindei] Wouldn't this undermine the purpose of having EntryMergePolicy implementations? Because ultimately if a conflict has occurred, surely we should always rely on the policies semantics, otherwise this would be very confusing to the user. 

> 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)