]
Bela Ban commented on JGRP-1309:
--------------------------------
Investigate whether staggering the responses makes any sense
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.
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 !
--
This message is automatically generated by JIRA.
For more information on JIRA, see: