This is interesting Bongjae.
Some questions:
Bongjae Chang wrote:
> Hi,
> Sometimes userswould like to know whether join finished completely or
> not.
> Like join, it is possible that users would like to knowsome events
> such asthe gms leaves the group completely as well.
> So if Shoalsupports GMS's StateListener, I think that it can beuseful.
> Here is the simple sample.
> ---
> public interface GroupManagementServiceStateListener {
> public void onStarted();
> public void onReady(); // or onJoined() or onMasterDiscovery()
> public void onStopped();
> public void onException(Throwable t);
> // etc...
> }
> ---
> A user implementsown listeners according tohis usecases and multiple
> listeners could exist.
> And a user adds listeners to gms like this.
> ---
> gms.addStateListener( userStateListener1 );
> gms.addStateListener( userStateListener2 );
> ---
At what point would GroupManagementService call the state listener's
onStarted() or onReady() methods ?
Would it be after the join() call returns? If yes, then that still does
not address the problem that Jerry is concerned with.
For instance, A joins group, B joins much later, B calls gms.join() and
as soon as that call returns, B calls groupHandle.sendMessage() thinking
that since join() returned, everything is a-okay to start messaging in
the group.
B needs to know when to send messages to the group so that any member
will receive it.
How does the above API solve that problem ? Assuming after join() GMS
calls GroupManagementStateListener.onStartup() how does that help the
client know that the joining has finished and all instances present at
the time in the group have in fact received the view related to the change?
If I understand the above correctly, the JoinNotificationSignal and the
JoinedAndReadyNotificationSignal already are performing the same role as
onStarted () and onReady(). The consumeSignal() method in the Signal(s)
does what these methods are purported to do. It seems to me that the
above is mostly a convenience from a ease-of-use perspective, rather
than actually solving the problem.
To me, it appears that gms.join() should have an optional block and
return capability so that in that mode it returns only when it knows
that others in the group have finished receiving the view change/signal
about its joining the group. This would allow the joining member send
messages to the group while being sure that others in the group know
about this member.
At this point since much of the join() work is done on background
threads in ClusterManager-->MasterNode-->HealthMonitor, etc., join()
returns a bit earlier than desirable.
So even if one were to register for a JoinNotificationSignal and get the
signal callback when one joins the group, it is still not a guarantee
that others in the group have seen this join event. In a large group of
members, that would particularly be the case as some members may be slow
to receive this event while in the joining member the join() call has
returned.
And, IMHO, the above API does not change that.
Please correct me if I am misunderstanding.
Cheers
Shreedhar
> And a user use the listener.
> ---
> gms.join();
> // wait for onReady();
> // when onReady() is notified, process gms operations
> ...
> ---
> What do you think?
> --
> Bongjae Chang