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