[jboss-jira] [JBoss JIRA] Commented: (JGRP-587) Lightweight FLUSH for state transfer

[Bela Ban (JIRA)]

    [ http://jira.jboss.com/jira/browse/JGRP-587?page=comments#action_12402069 ] 
            
Bela Ban commented on JGRP-587:
-------------------------------

I'll downgrade this issue again, as we already have light-weight flushing with the shared transport: every channel has its own copy of the stack (including FLUSH), and only the transport is shared. So flushing will affect only the channels which are part of the same cluster

> Lightweight FLUSH for state transfer
> ------------------------------------
>
>                 Key: JGRP-587
>                 URL: http://jira.jboss.com/jira/browse/JGRP-587
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.7
>
>
> We should investigate introduction of lightweight FLUSH in Multiplexer. Lightweight FLUSH would introduce stop-the-world model to only specific mux application leaving other mux applications unaffected. For example, if there are three mux applications A,B, and C and we need to FLUSH only application C, lightweight FLUSH would block all message sending for C only while applications A and B are unaffected. 
> For Multiplexer, JOIN's will still need to block everyone, because we're actually creating the underlying JChannel.
> For state transfer on the Multiplexer, the example should be:
> - Members {A,B,C}. A and B have services X and Y, C has only service Y
> - Service B.X requests a state transfer (MuxChannel.getState())
> - The FLUSH needs to be qualified with the service-id: FLUSH(X)
> - A, B and C receive a START-FLUSH(X) message, which invokes A.X.block(), B.X.block().
> - For C, since there is no X service, Multiplexer.block() simply returns
> - When A has received all FLUSH-OK messages from A, B and C, we transfer the state from A.X to B.X
> - Then we terminate the FLUSH by sending a STOP-FLUSH(x) to {A,B,C}
> - This again calls A.X.unblock(), B.X.unblock() and is a no-op for C
> This allows other services, e.g. Y, to be unaffected (ie., non-blocked) by the flushing of A.X

-- 
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