[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=13343294#comment-13343294 ] 

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

I found out that this has nothing to do with AUTH or ASYM_ENCRYPT, but with MERGE3 possibly being able to send incorrect MERGE events up the stack, e.g.
* The view is A1={A,B}
* Now we're injecting A2={A} and B2={B} into MERGE3 as a MERGE event
* ==> This will trigget duplicate view installation as GMS doesn't check if the members of a given view are the same as those of the existing view. 
Unit test: DuplicateMergeViewTest.

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