[jboss-jira] [JBoss JIRA] Updated: (JGRP-332) Support concurrent flushing

[Vladimir Blagojevic (JIRA)]

     [ 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