[ https://issues.jboss.org/browse/JGRP-1315?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1315: -------------------------------- For discovery requests triggered by GMS (JOIN), every member returns: - UUID - Logical name - Physical address For discovery requests triggered by MERGE2, every member returns: - *ViewId* (instead of View) For merge-triggered discovery requests, MERGE2 only checks if ViewIds differ. If they do, a merge is initiated. --> We do not need to send the entire Views, which saves space on large clusters - -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1315?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1315 at 8/11/11 11:20 AM: ---------------------------------------------------------- For discovery requests triggered by GMS (JOIN), every member returns: - Its own address (UUID) - Its logical name - Its physical address - The coordinator's address (UUID) For discovery requests triggered by MERGE2, every member returns: - *ViewId* (instead of View) For merge-triggered discovery requests, MERGE2 only checks if ViewIds differ. If they do, a merge is initiated. --> We do not need to send the entire View, which saves space on large clusters Further optimization: - With MERGE2, the coordinator sends its ViewId along with the discovery request. Only members whose ViewId differ, send a discovery response --> Say we have 3 partitions --> If we have 100 members, the existing code sends 100 discovery responses, whereas the new code would send 2 responses ! was (Author: belaban): For discovery requests triggered by GMS (JOIN), every member returns: - UUID - Logical name - Physical address For discovery requests triggered by MERGE2, every member returns: - *ViewId* (instead of View) For merge-triggered discovery requests, MERGE2 only checks if ViewIds differ. If they do, a merge is initiated. --> We do not need to send the entire View, which saves space on large clusters Further optimization: - With MERGE2, the coordinator sends its ViewId along with the discovery request. Only members whose ViewId differ, send a discovery response --> Say we have 3 partitions --> If we have 100 members, the existing code sends 100 discovery responses, whereas the new code would send 2 responses ! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1315?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1315 at 8/12/11 5:35 AM: --------------------------------------------------------- For discovery requests triggered by GMS (JOIN), every member returns: - Its own address (UUID) - Its logical name - Its physical address - The coordinator's address (UUID) For discovery requests triggered by MERGE2, every member (whose ViewId differs) returns: - View However, for a merge-triggered discovery request, the merge cooordinator sends its *ViewId* with the request. Only members who have *differing* ViewIds return their View. --> Say we have 3 partitions --> If we have 100 members, the existing code sends 100 discovery responses, whereas the new code would send 2 responses ! --> We do not need to send the entire View, which saves space on large clusters Further optimization: - Add a staggering timeout: --> Every member picks a random value in the range [0..timeout] and waits that amount of timeout before it sends the response. This will prevent traffic bursts. Timeout=0 means don't stagger the response. was (Author: belaban): For discovery requests triggered by GMS (JOIN), every member returns: - Its own address (UUID) - Its logical name - Its physical address - The coordinator's address (UUID) For discovery requests triggered by MERGE2, every member returns: - *ViewId* (instead of View) For merge-triggered discovery requests, MERGE2 only checks if ViewIds differ. If they do, a merge is initiated. --> We do not need to send the entire View, which saves space on large clusters Further optimization: - With MERGE2, the coordinator sends its ViewId along with the discovery request. Only members whose ViewId differ, send a discovery response --> Say we have 3 partitions --> If we have 100 members, the existing code sends 100 discovery responses, whereas the new code would send 2 responses ! - Add a stagger timeout: --> Every member picks a random value in the range [0..timeout] and waits that amount of timeout before it sends the response. This will prevent traffic bursts. Timeout=0 means don't stagger the response. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1315?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1315. ---------------------------- Resolution: Done -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira