[jboss-jira] [JBoss JIRA] Updated: (JGRP-1309) Discovery: max_rank doesn't make any sense

[Bela Ban (JIRA)]

     [ https://issues.jboss.org/browse/JGRP-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1309:
---------------------------

    Description: 
Discovery.max_rank was originally meant to reduce traffic in the discovery phase: rather than 100 members replying to a discovery request, only the coordinators (max_rank=1) would reply and this would be enough for a joiner to find the coordinator and send it a JOIN request.

However, discovery responses also contain additional information, such as the logical name (if set) and the physical address of a member. This is needed by all members of a cluster, and so everyone should return this information to a new joiner.

Therefore, when we set a max_rank, we also need to set return_entire_cache=true (this is done automatically by ergonomics) !

Seen under this aspect, max_rank is useless and even conter-productive !
If we have 100 members:
- max_rank=0: we get 100 discovery responses (1 response from each member)
- max_rank=1 (sets return_entire_cache to true): the coordinator returns the entire cache to the joiner (1 unicast / cache entry: 100 unicasts)
- max_rank=2: the coordinator plus the next in line return the entire cache: 200 unicasts
- and so on

The current problem is that ergonomics sets return_entire_cache which - in conjunction with max_rank > 0 - generates even more discovery responses than is max_rank is 0 !

  was:
Discovery.max_rank was originally meant to reduce traffic in the discovery phase: rather than 100 members replying to a discovery request, only the coordinators (max_rank=1) would reply and this would be enough for a joiner to find the coordinator and send it a JOIN request.

However, discovery responses also contain additional information, such as the logical name (if set) and the physical address of a member. This is needed by all members of a cluster, and so everyone should return this information to a new joiner.
Seen under this aspect, max_rank is useless and even conter-productive !
If we have 100 members:
- max_rank=0: we get 100 discovery responses
- max_rank=1 (sets return_entire_cache to true): the coordinator return the entire cache to the joiner (1 unicast / cache entry: 100 unicasts)
- max_rank=2: the coordinator plus the next in line return the entire cache: 200 unicasts
- and so on

The current problem is that ergonomics sets return_entire_cache which - in conjunction with max_rank > 0 - generates even more discovery responses than is max_rank is 0 !



> Discovery: max_rank doesn't make any sense
> ------------------------------------------
>
>                 Key: JGRP-1309
>                 URL: https://issues.jboss.org/browse/JGRP-1309
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.0
>
>
> Discovery.max_rank was originally meant to reduce traffic in the discovery phase: rather than 100 members replying to a discovery request, only the coordinators (max_rank=1) would reply and this would be enough for a joiner to find the coordinator and send it a JOIN request.
> However, discovery responses also contain additional information, such as the logical name (if set) and the physical address of a member. This is needed by all members of a cluster, and so everyone should return this information to a new joiner.
> Therefore, when we set a max_rank, we also need to set return_entire_cache=true (this is done automatically by ergonomics) !
> Seen under this aspect, max_rank is useless and even conter-productive !
> If we have 100 members:
> - max_rank=0: we get 100 discovery responses (1 response from each member)
> - max_rank=1 (sets return_entire_cache to true): the coordinator returns the entire cache to the joiner (1 unicast / cache entry: 100 unicasts)
> - max_rank=2: the coordinator plus the next in line return the entire cache: 200 unicasts
> - and so on
> The current problem is that ergonomics sets return_entire_cache which - in conjunction with max_rank > 0 - generates even more discovery responses than is max_rank is 0 !

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira