[
https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1705:
--------------------------------
Possible solutions:
* Key {{views}} by sender and not by ViewId. This would overwrite C's INFO=A|5 with
INFO=A|6 in the case where C sends multiple INFO messages before the {{views}} table is
looked at by ViewConsistencyChecker
* Clear the {{views}} table after a new view is installed
* Wait for {{max_interval + offset}} after clearing {{views}} to make sure we've
received all current view-ids
MERGE3 handles fake merge views
-------------------------------
Key: JGRP-1705
URL:
https://issues.jboss.org/browse/JGRP-1705
Project: JGroups
Issue Type: Bug
Affects Versions: 3.4
Reporter: Karim AMMOUS
Assignee: Bela Ban
Fix For: 3.4
Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
Under some conditions, MERGE3 handles fake merge views. After "merge", number
of members that form the cluster still the same and the mergeView contains only one
subgroup.
Scenario:
- Form a large cluster (1115 mbrs)
- Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
- Reboot one machine (172.29.190.5) hosting 7 JVMs
- Coord install a new view with 1108 mbrs.
When new members join the cluster we observe a merge view formed by only one subgroup.
Coordinator log file was attached to this JIRA.
--
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