[
https://jira.jboss.org/jira/browse/JGRP-1025?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1025:
--------------------------------
Regarding overlapping flushes:
it should be possible to handle cases like this:
A: BAC
B: BC
C: BC
Merge coordinator is B and merge participants are B and A. When B receives the merge
request, it tries to flush B and C. When A receives the merge request, it tries to flush
A, B and C. However, B and C will discard the flush request from A (because A is not a
member in their view) and therefore, the flush from A will fail !
SOLUTION #1: flush only disjoint partitions, e.g. B flushes {B,C} while A flushes only
{A}. However, we can not be sure that we can always achieve this (disjoint partitions). So
maybe an additonal / complimentary solution would be
SOLUTION #2: pass an 'owner' to a flush. Default is the flush initiator, but if
owner is passed, it will be the latter. In the above case, owner could be the merge-id and
is as such passed to A and B. The same owner can lock multiple times, after the first
time, locking is a no-op (see above).
Solution #2 doesn't of course apply to the above case, but it will harden FLUSH
anyway, for cases where we cannot prevent overlapping merges (and thus overlapping
flushes)
Harden FLUSH
------------
Key: JGRP-1025
URL:
https://jira.jboss.org/jira/browse/JGRP-1025
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Vladimir Blagojevic
Fix For: 2.9
Make sure no FLUSH is left hanging, e.g. due to the crash of the flush leader after the
START-FLUSH round.
In other words, make analyze the code and make sure STOP-FLUSH is eventually called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira