[jboss-jira] [JBoss JIRA] Commented: (JGRP-236) Combine join and state transfer

[Vladimir Blagojevic (JIRA)]

    [ 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