[jboss-jira] [JBoss JIRA] (JGRP-1841) Static discovery protocol

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969631#comment-12969631 ] 

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)