[infinispan-issues] [JBoss JIRA] (ISPN-3731) Multicast messages can be replayed to new node

Dan Berindei (JIRA) issues at jboss.org
Tue Dec 17 10:26:33 EST 2013


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

Dan Berindei commented on ISPN-3731:
------------------------------------

I believe ignoring commands with a topology id lower than the initial topology id won't work, because the initial topology id doesn't contain the joiner yet. So if the cluster is {{[2|A, B]}} with topology 2 and {{C}} joins, C's initial topology will still be 2, and a command broadcasted by {{B}} with a topology id of 2 will still be replayed on {{C}}.

I'm thinking of keeping track of the first topology where {{C}} is a member instead, and ignoring all commands with a lower topology id. Luckily, even nodes with a capacity factor of {{0}} will be a member in the CH, so I don't think this should cause any problems.

I will also remove the broadcast optimization, since switching between unicast and broadcast breaks the ordering of asynchronous messages. Unfortunately, eliminating the broadcast optimization would only fix this bug for dist mode, in repl mode it would still be possible for a joiner to apply a transaction outside of the primary owner's lock.
                
> Multicast messages can be replayed to new node
> ----------------------------------------------
>
>                 Key: ISPN-3731
>                 URL: https://issues.jboss.org/browse/ISPN-3731
>             Project: Infinispan
>          Issue Type: Bug
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Vansa
>            Assignee: Dan Berindei
>            Priority: Critical
>              Labels: 620
>
> Messages that target all current members are sent as multicast messages.
> However, these retransmissions can be replayed on new nodes that have just joined the cluster.
> This can result for example in execution of already completed transaction on the new node, causing possible data inconsistency for those entries which are owned by the new node in backup way - the replayed transaction sequence authoritatively overwrites them.
> The node should remember the first topologyId it has seen and do not execute any commands that have lower topologyId.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the infinispan-issues mailing list