[
https://issues.jboss.org/browse/JGRP-1841?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1841:
--------------------------------
When running on a cloud, e.g. Google Compute Engine, generation of the config file could
be automatic, e.g. one could start all of the instances first, then list them:
{noformat}
mac] /Users/bela$ gcutil listinstances|grep us-centr
| box1 | us-central1-b | RUNNING | 10.240.89.133 | 107.178.218.232 |
| box2 | us-central1-b | RUNNING | 10.240.89.152 | 107.178.217.150 |
| box3 | us-central1-b | RUNNING | 10.240.169.106 | 107.178.211.27 |
{noformat}
Now the config file could be generated by giving instances increasing UUIDs, e.g
{noformat}
box1 | 1 | 10.240.89.133:7800
box2 | 2 | 10.240.89.152:7800
box3 | 3 | 10.240.169.106:7800
{noformat}
Next, the instances could be started in the order of box1, box2, box3, ...
Static discovery protocol
-------------------------
Key: JGRP-1841
URL:
https://issues.jboss.org/browse/JGRP-1841
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
A new protocol which lists *all* members in the following format:
|| Logical name || UUID || IP address:port ||
| A | 1 | 192.168.1.5:7800 |
| B | 2 | 192.168.1.6:7800 |
| C | 3 | 192.168.1.7:7800 |
On startup, the static discovery protocol reads this file and populates the
{{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
Once this is done, there is no need for lookups as the caches should have the complete
information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max
number of nodes.
When nodes are started, they need to be given the logical name and UUID indicated in the
file. The former can be done via {{JChannel.name(String name)}}, the latter should be done
via an {{AddressGenerator}}.
Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently
reconnected, the address generator should pick a different UUID (perhaps a random one).
This should be reflected in the config file as well.
Also, nodes need to be started in the order in which they are listed, so we can ping the
first nodes for coordinatorship.
The goals of this protocol are:
* Used when IP multicast is not available
* Quick startup
* Large clusters: using N-1 for multicast simulation quickly generates too much traffic
in the discovery phase
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)