>> Do you see a view change with the two members in it ?
>>
> Yes, I do.
>
>> If your send() is around the same time as the time the view change
>> happens then you will have message loss.
>>
>
> Ah. This must be it. Since the join and send happen immediately one after the
> other, its quite likely that the send happens while the existing peers are
> processing the view change.
>
>
>> Also, with Shoal 1.1 we have made a lot of synchronization improvements
>> for correctness, which may have cost somewhat at the time of startup of
>> members.
>>
>> Could you try out the code snippet that Joe provided as a way to ensure
>> that message sending happens only when requisite memberships in the
>> group are in place ?
>>
>
> I have no pre-existing knowledge of the number of expected peers. So waiting for
> "all" of them to join has no real meaning for me. The idea here is that peers
> can join and leave as they please. The message they send as soon as they join is
> used by existing peers (if any) to gain certain data about the new peer (its IP
> address, port its listening on etc). So the code from below will not really work
> for me, since I have no idea if any more peers will join or not.
>
> I can live with having a sleep between join and send for now, except it seems
> rather non-deterministic: are we always sure that 5 secs is enough? Under load
> will this go up? A clear callback or signal that says "It is now safe to send
> messages" will be much better.
>
Timing is always a challenge when there are distributed systems involved
and larger the number of members, the more involved it gets to ensure
virtual synchrony especially on asynchronous systems. We could
eventually look at an ack based system for membership lifecycle events'
view change messages, but there are costs with that as well when
memberships are large.
One suggestion that may make it a bit better is that you could use the
joined and ready construct for letting the group know that you are ready
to receive and send messages. i.e when a member has connected to the
group you get a join notification signal. After this when the member is
ready to send messages, it can call the reportJoinedAndReadyState() API
from the GroupManagementService reference
http://fisheye5.cenqua.com/browse/~raw,r=1.16/shoal/gms/src/java/com/sun/enterprise/ee/cms/core/GroupManagementService.java
Members who have registered for receiving the joined and ready
notification signal and have joined the group would get that
notification and then can send out messages to that member.
Hope this helps you get a bit closer to deterministic knowledge of when
a member(or set of members is/are ready to receive messages.
> -Jerry
>
>
>> Thanks
>> Shreedhar
>>
>>
>>> The same identical code worked fine with Shoal 1.0.
>>>
>>> I hope this clarifies the use-case.
>>> -Jerry
>>>
>>>
>>>
>>>> However, there is not enough information in your original post to
>>>> confirm or deny this.
>>>>
>>>> You could delay sending a message to the group until there is certain
>>>> number of members joined or
>>>> you could wait for all members to have joined via JoinNotification event.
>>>>
>>>> Pull API:
>>>>
>>>> List<String> members = gms.getGroupHandle().getAllCurrentMembers();
>>>> <wait to send first message until all expected number of members have
>>>> joined>
>>>>
>>>> Event driven API:
>>>>
>>>> gms.addActionFactory( new JoinNotificationActionFactoryImpl( new
>>>> JoinNotificationCallBack( serverName ) ) );
>>>> gms.join();
>>>> <wait till all expected instances have joined before sending message;
>>>> use info calculated from JoinNotificationCallback>
>>>>
>>>> private class JoinNotificationCallBack implements CallBack {
>>>>
>>>> private String serverName;
>>>>
>>>> public JoinNotificationCallBack( String serverName ) {
>>>> this.serverName = serverName;
>>>> }
>>>>
>>>> // called for every instance joining the gms group.
>>>> public void processNotification( Signal notification ) {
>>>> <record instance has joined>;
>>>> }
>>>> }
>>>>
>>>> A non-coding way to check this out is to start all your receiving
>>>> clients first.
>>>> Wait 10 seconds (like your initial test).
>>>> Then start your sending gms client.
>>>> There is no need a sleep between the join and send since all the other
>>>> members
>>>> will have already joined. Hope this helps.
>>>>
>>>> -Joe
>>>>
>>>>
>>>>> Thanks
>>>>> -Jerry
>>>>>
>>>>> Jerry Raj wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hello,
>>>>>> I have code like this:
>>>>>> <snip>
>>>>>> gms.join();
>>>>>> // Commented: Thread.sleep(10000);
>>>>>> GroupHandle gh = gms.getGroupHandle();
>>>>>>
>>>>>> gh.sendMessage(blah);
>>>>>>
>>>>>> </snip>
>>>>>>
>>>>>> This used to work fine in Shoal 1.0. The node would join the group
>>>>>> and the
>>>>>> message would be recd by other members in the group. But this does
>>>>>> not happen
>>>>>> with Shoal 1.1 unless I uncomment the sleep(10000) between join() and
>>>>>> send(). I
>>>>>> expect this is because the join operation has not completed
>>>>>> successfully when
>>>>>> send() is called. Is there a way to be notified when join is
>>>>>> complete? I tried
>>>>>> looking at JoinedAndReadyNotificationActionImpl but that does not
>>>>>> seem to work?
>>>>>>
>>>>>> I'm using Shoal 1.1 from the download link on the front page of the
>>>>>> Shoal website.
>>>>>>
>>>>>> -Jerry
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net <mailto:users-unsubscribe_at_shoal.dev.java.net>
>>>>> For additional commands, e-mail: users-help_at_shoal.dev.java.net <mailto:users-help_at_shoal.dev.java.net>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net <mailto:users-unsubscribe_at_shoal.dev.java.net>
>>>> For additional commands, e-mail: users-help_at_shoal.dev.java.net <mailto:users-help_at_shoal.dev.java.net>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net <mailto:users-unsubscribe_at_shoal.dev.java.net>
>>> For additional commands, e-mail: users-help_at_shoal.dev.java.net <mailto:users-help_at_shoal.dev.java.net>
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>
>