[jboss-jira] [JBoss JIRA] (JGRP-2136) Merge installs the same view

[Bela Ban (JIRA)]

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

Bela Ban commented on JGRP-2136:
--------------------------------

OK, I'll revert the code which prevents duplicate consecutive MergeViews; the application has to be able to handle this (also updated the manual on MergeView). Otherwise, edge merge cases like the one above would not get handled properly.

Note that regular consecutive views are not affected: they never have duplicate membership.

> Merge installs the same view
> ----------------------------
>
>                 Key: JGRP-2136
>                 URL: https://issues.jboss.org/browse/JGRP-2136
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.6.12, 4.0
>
>
> The cluster is A,B with AUTH and ASYM_ENCRYPT. When a rogue member C (whith an incorrect auth_value in AUTH) attempts to join, it will be rejected by AUTH. However, while the subsequent merge attempts also fail (as designed), this leads to spurious MergeView installations in A and B, e.g.:
> {noformat}
> ** View=[belasmac-17416|1] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|2] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|1] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|3] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|2] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|4] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|3] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|5] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|4] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|6] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|5] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|7] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|6] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|8] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|7] (2) [belasmac-17416, belasmac-56188]
> {noformat}
> This neither corrupts security of the system (the rogue member cannot merge-join) nor correctness, but we need to prevent the spurious views. Systems like Infinispan might start a rebalance on a view, regardless of whether they are the same as before or not.
> SOLUTION: the merge leader needs to see if the MergeView it is about to send out is the same as the current view, and simply drop it if that's the case.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)