[ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1705: -------------------------------- I see 2 scenarios where this can happen: h5. Member sends old view before new view is received The InfoSender task at a member kicks in just before a new view is received, and thus the member sends the old view. Example: * The view is \{A,B,C,D\} * A installs new view A|5 (the old view is A|4) * Just before receiving A|5, C's InfoSender sends an INFO with view=A|4 to the coordinator (A) * Everybody else sends an INFO with view=A|5 to A * A now has 2 views A|4 and A|5 and starts the merge process Actually, before this happens, the coordinator asks A (itself) and C for their actual views and only starts the merge process if the actual views differ; this as a second line of defense against a spurious merge. h5. Coordinator's 'views' table contains outdated information The coordinator maintains a 'views' table, which is a hashmap keyed by ViewId. The problem is that if the coord receives 2 INFO messages from the same sender, but with different ViewIds, then the merge process is triggered as well: * C sends INFO=A|5 * The views table contains A|5=[C] * A installs A|6 and C sends INFO=A|6 * The views table contains A|5=[C], A|6=[C] // ommitting the INFO messages from other members Again, fetching the real views before triggering a merge should remedy this, but there's still a time window where this can happen -- 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