[jboss-jira] [JBoss JIRA] Commented: (JGRP-735) Discovery: ignore discovery responses from clients

[Bela Ban (JIRA)]

    [ http://jira.jboss.com/jira/browse/JGRP-735?page=comments#action_12409519 ] 
            
Bela Ban commented on JGRP-735:
-------------------------------

[Michael Newcomb]
Upon further thinking on this issue, it seems that when discovering
existing 'members', PingRsp objects that come back with
PingRsp.is_server == true need to be treated differently than those
PingRsp objects with PingRsp.is_server == false...

Right now, they are treated the same and *both* count towards
num_initial_members which can cause problems in concurrent startup
situation because the concurrently starting members might receive
PingRsp objects from other concurrently starting members
(PingRsp.is_server == false), hit the num_initial_members threshold, and
trigger formation of a new group.

So, I think there needs to be a shortcut in Discovery.Responses when a
PingRsp is added, it should be checked to see if it is a real member
(PingRsp.is_server == true). If it is it could signal the awaiting
promise? This would effectively eliminate all wait times associated with
joining an existing group because as soon as you receive a response from
a real member, you would join his coordinator.

I think you should join the first coordinator you see, because it is the
most likely case and if you have more than one coordinator, a merge is
most likely in place and even with the voting process, there is no
guarantee that you selected the winning coordinator anyway (may have
missed the 'lowest addresses' coordinator or missed a PingRsp that would
have made one coordinator have more votes than another, etc...).

If you are not a coord (PingRsp.isCoord() == false), you should behave
as normal and just count towards the 'num_initial_members' threshold or
the full timeout as normal.

> Discovery: ignore discovery responses from clients
> --------------------------------------------------
>
>                 Key: JGRP-735
>                 URL: http://jira.jboss.com/jira/browse/JGRP-735
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.7, 2.8
>
>
> If we have 9 joining members (starting simultaneously) and 1 operational member X, and
> num_initial_rsps=5 and
> timeout=3000
> ,then a joining member might receive 5 responses from other joining clients and *not* the one from the existing member. 
> This is good when we have *initial* concurrent startups, but not when we have existing 'well-known' operational members running.
> FEATURE: add a flag 'ignore-client-responses' which will collect only responses from operational members (servers). In the above case, each joining member will either get a response from X, or time out after 5 secs. We could also define a min_operational_resps, which (enabled if > 0) defines the minimum number of responses which need to be received from operational member and ignores responses from client members.
> WORKAROUND: increase num_initial_mbrs and timeout

-- 
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