[
http://jira.jboss.com/jira/browse/JGRP-332?page=all ]
Vladimir Blagojevic updated JGRP-332:
-------------------------------------
Description:
JGroups 2.4 introduces FLUSH protocol that enables stop-the-world model for JGroups nodes.
However, FLUSH protocol currently does not support coordination between nodes when it
comes to concurrent requests for flush.
Problem 1)
If there are concurrent requests for flush (e.g. every node concurrently does
channel.getState()) FLUSH should deterministically chose a winner flush request and other
nodes should retry flush.
Problem 2)
If more than one MuxChannel sitting on top of JChannel requests flush then node has to
again deterministically determine a winner request and other MuxChannels should retry.
was:JGroups 2.4 introduces FLUSH protocol that enables stop-the-world model for JGroups
nodes. However, FLUSH protocol currently does not support coordination between nodes when
it comes to concurrent requests for flush. For example, in JGroups 2.4 if more than one
MuxChannel sitting on top of JChannel requests flush the behaviour is nondeterministic.
Also, we should investigate how to combine concurrent flush requests coming from state
transfer protocol with flush requests coming from GMS protocol.
Support concurrent flushing
---------------------------
Key: JGRP-332
URL:
http://jira.jboss.com/jira/browse/JGRP-332
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.4
Reporter: Vladimir Blagojevic
Assigned To: Vladimir Blagojevic
Fix For: 2.5
JGroups 2.4 introduces FLUSH protocol that enables stop-the-world model for JGroups
nodes. However, FLUSH protocol currently does not support coordination between nodes when
it comes to concurrent requests for flush.
Problem 1)
If there are concurrent requests for flush (e.g. every node concurrently does
channel.getState()) FLUSH should deterministically chose a winner flush request and other
nodes should retry flush.
Problem 2)
If more than one MuxChannel sitting on top of JChannel requests flush then node has to
again deterministically determine a winner request and other MuxChannels should retry.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira