]
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.