[jboss-jira] [JBoss JIRA] (JGRP-1809) New discovery protocol to be used in conjunction with SHARED_LOOPBACK

Bela Ban (JIRA) issues at jboss.org
Fri Mar 21 07:56:11 EDT 2014


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

Bela Ban updated JGRP-1809:
---------------------------

    Description: 
Sometimes tests in the testsuite fail because the nodes run over SHARED_LOOPBACK fail to discover each other and therefore don't form a cluster. This can happen because discovery requests sent via PING are discarded on a full thread pool.
Because the default test stack doesn't have a MERGE protocol, members won't get merged back.

h5. GOAL
* Create a discovery protocol which always discovers other members registered with the same cluster 

h5. SOLUTION
* Instead of using SHARED_LOOPBACK to send and receive discovery requests, query SHARED_LOOPBACK directly for discovery information. E.g. if we have members A,B,C registered with cluster "demo" in SHARED_LOOPBACK, then a node D joining can fetch (via SHARED_LOOPBACK_PING) the PingData of A, B and C directly from SHARED_LOOPBACK.
* This way, we won't have any failed test cases (run over SHARED_LOOPBACK) which fail because no other members were discovered. Also, discovery (even for the first node started in a cluster) is very fast, and we don't need the timeout at all.
* Also, we don't need to add a MERGE protocol to the stack as merging is not needed

  was:
Sometimes tests in the testsuite fail because the nodes run over SHARED_LOOPBACK fail to discover each other and therefore don't form a cluster. This can happen because discovery requests sent via PING are discarded on a full thread pool.
Because the default test stack doesn't have a MERGE protocol, members won't get merged back.

h5. GOAL
* Create a discovery protocol which always discovers other members registered with the same cluster 

h5. SOLUTION
* Instead of using SHARED_LOOPBACK to send and receive discovery requests, query SHARED_LOOPBACK directly for discovery information. E.g. if we have members A,B,C registered with cluster "demo" in SHARED_LOOPBACK, then a node D joining can fetch (via SHARED_LOOPBACK_PING) the PingData of A, B and C directly from SHARED_LOOPBACK.
This way, we won't have any failed test cases (run over SHARED_LOOPBACK) which fail because no other members were discovered. Also, discovery (even for the first node started in a cluster) is very fast, and we don't need the timeout at all.


    
> New discovery protocol to be used in conjunction with SHARED_LOOPBACK
> ---------------------------------------------------------------------
>
>                 Key: JGRP-1809
>                 URL: https://issues.jboss.org/browse/JGRP-1809
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> Sometimes tests in the testsuite fail because the nodes run over SHARED_LOOPBACK fail to discover each other and therefore don't form a cluster. This can happen because discovery requests sent via PING are discarded on a full thread pool.
> Because the default test stack doesn't have a MERGE protocol, members won't get merged back.
> h5. GOAL
> * Create a discovery protocol which always discovers other members registered with the same cluster 
> h5. SOLUTION
> * Instead of using SHARED_LOOPBACK to send and receive discovery requests, query SHARED_LOOPBACK directly for discovery information. E.g. if we have members A,B,C registered with cluster "demo" in SHARED_LOOPBACK, then a node D joining can fetch (via SHARED_LOOPBACK_PING) the PingData of A, B and C directly from SHARED_LOOPBACK.
> * This way, we won't have any failed test cases (run over SHARED_LOOPBACK) which fail because no other members were discovered. Also, discovery (even for the first node started in a cluster) is very fast, and we don't need the timeout at all.
> * Also, we don't need to add a MERGE protocol to the stack as merging is not needed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the jboss-jira mailing list