[
http://jira.jboss.com/jira/browse/JGRP-236?page=comments#action_12369126 ]
Vladimir Blagojevic commented on JGRP-236:
------------------------------------------
Implementing JChannel#connect(String cluster_name, Address target, String state_id, long
timeout)
In JChannel#connect client finds initial members and determines coordinator (JGRP-420)
In JChannel#connect client requests from coordinator to do first flush phase on its behalf
and does not proceed until coordinator responds that first flush phase succeeded (current
surviving members are flushed and blocked down)
In JChannel#connect client sends down CONNECT_WITH_TRANSFER event
In ClientGmsImpl client traps CONNECT_WITH_TRANSFER and sends JOIN_WITH_TRANSFER (or JOIN
with transfer flag) to coordinator (no need to detemine coordinator;already done in first
step)
Coordinator handles JOIN_WITH_TRANSFER (or JOIN with transfer flag) similarly as regular
JOIN except we change handleMembershipChange to include use_flush boolean parameter (thus
coordinator will not request another flush)
Coordinator invokes handleMembershipChange where use_flush is false, new view is
determined and sent; acked by members
In JChannel#connect state is requested by joining client which sends down GET_STATE
(StateTransferInfo contains use_flush flag which is false;no flush is thus requested)
In JChannel#connect state transfer succeeds or fails
In JChannel#connect requests stop flush; both surviving members and new member are
unblocked down
In JChannel#connect returns
Multiple concurrent joins where some joinging members require transfer and some not is
handled by CoordGmsImpl#handleMembershipChange. As soon as we have at least one member
requesting join and state transfer we need to invoke CoordGmsImpl#handleMembershipChange
with use_flush parameter being false since that member already triggered flush (see step
2).
Combine join and state transfer
-------------------------------
Key: JGRP-236
URL:
http://jira.jboss.com/jira/browse/JGRP-236
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.2.8, 2.2.9, 2.3, 2.2.9.1, 2.2.9.2
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.6
Add an additional connect(String group_name, boolean fetch_state, String state_id) method
to Channel, so that we can combine joining and state transfer into 1 operation. This also
requires only 1 FLUSH phase.
The state would be returned either via pulling with Channel.receive() or pushing the
setState() method in a registered Receiver/MessageListener.
- The JOIN_REQ contains the boolean
- The algorithm in GMS is the same as the two described above, except that before
multicasting the new view and sending
the JOIN_RSPs and LEAVE_RSPs, we ask the application for its state (GET_APPLSTATE) and
when received (GET_APPLSTATE_OK),
we send it back to the joining member(s), and the RESUME sending messages
--
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