Hi Shreedhar,
Thank you for your feedback. I wrote some comments. Please see the following.
Shreedhar wrote:
>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.
It is difficult for me to determine the point now. When I read the Jerry's question, I suddenly had an idea such as controlling server-side lifecycle.
Actually, I just would like to receive your opinions and discuss it. :)
Here was my first thought.
---
onStarted() --> after join()
onReady() --> after finishing discovery and setting up all modules.
...
---
Shreedhar wrote:
>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.
You are right.
Additionally, I thought that JoinNotificationSignal and JoinedAndReadyNotificationSignal were close to GMS's purpose, but onStarted() and onReady() were close to the purpose of the server(member) instance itself.
For instance, JoinNotificationSignal means that members which include other members as well as itself join the group, but we don't know if members are ready.
It means the member just joins the group. At this point, the member can be on starting or be started or be on ready. We just know that the member joins the cluster.
It could be not concerned with the server lifecycle.
And we could think about JoinedAndReadyNotification. JoinedAndReadyNotification will be notified when a user calls GroupManagementService#reportJoinedAndReadyState() manually. So I thought that the notification was close to the user(application)'s ready event.
It could be also not concerned with the server lifecycle.
Of cource, for notifying JoinedAndReadyNotification, the server should be on ready. But if the internal implementation will be changed later, it could be not clear purpose.
So I would like to clarify the point between GMS's event and server's lifecycle.
Shreedhar wrote:
>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.
I agree with you. I also think that this feature is also good enhancement in current version.
After all, my ultimate purpose was like the following.
- managing internal server state
- separating internal server logic from gms logic
- after server is on ready, all gms event and operation will be processed.
For instance,
-> gms.start()
--> starting
--> on started
--> on ready
--> all internal server modules are ready
-> explicit gms.join() and receiving all notifications and sending messages
-> gms.leave()
-> gms.shutdown()
--> stopping
--> on stopped
But, as your words, we can use JoinNotification and JoinedAndReadyNotification adequately without server's lifecycle in current version.
Thanks!
--
Bongjae Chang
----- Original Message -----
From: Shreedhar Ganapathy
To: dev_at_shoal.dev.java.net
Sent: Sunday, June 21, 2009 6:54 AM
Subject: Re: [Shoal-Dev] About supporting GMS's state listener
This is interesting Bongjae.
Some questions:
Bongjae Chang wrote:
Hi,
Sometimes users would like to know whether join finished completely or not.
Like join, it is possible that users would like to know some events such as the gms leaves the group completely as well.
So if Shoal supports GMS's StateListener, I think that it can be useful.
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 implements own listeners according to his 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