[
https://jira.jboss.org/jira/browse/JGRP-844?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-844:
-------------------------------
Seems like the case you described can be solved by keying the cache on the cluster name:
In step 3, since there is no entry in the cache for "2", B will actually run the
discovery phase and - since it gets no response for "2" - become a singleton
member.
As soon as view information becomes available (when a node has joined the cluster), we
replace the (discovery) cache entries with the contents of the view, also per cluster
name.
Discovery: make it a singleton with a shared transport
------------------------------------------------------
Key: JGRP-844
URL:
https://jira.jboss.org/jira/browse/JGRP-844
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
When we have a shared transport and 5 channels on top of it, then every channel will run
the discovery protocol. If it is the first node in a cluster, this will take <5 *
Discovery.timeout> ms.
Now, if the 5 channels didn't just share the transport, but also the discovery
protocol, then only the first channel to start would have to wait for Discovery.timeout
ms. It would then cache the results of that discovery and, when view changes are received,
replace the contents of the cache with view information.
The remaining 4 channels would then not even need to run the discovery phase, but the
discovery protocol would simply use the current view to return the coordinator. This means
that instead of 5 * timeout, we have 1 * timeout !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira