On Jun 16, 2010, at 9:45 AM, Kevan Miller wrote:
>
> On Jun 10, 2010, at 10:43 PM, David Blevins wrote:
>
>> If I understand correctly, then right on all points.
>>
>> To recap for possible doc benefit, sounds like this is the setup.
>>
>> client -> server1 -> server2 -> server3
>>
>> That should definitely work, but the start order would have to be the exact
>> opposite:
>>
>> server3, server2, server1, client
>
> The start order would not need to be "exactly" that strict, correct? servers
> 1, 2, and 3 could be started in any order. And even if client was already
> connected to server1, client could eventually learn of all potential
> servers...
The connection attempt is only made once when the server starts, so if that
server is not running they will never be linked... at least not without some
extra help.
If you started them in "front" order using the exact described setup with
server1 listing server2, server2 listing server1 and server3 listing nothing:
1. server1 starts; first it will attempt to connect to server2, which is not
running. So server1 will sit there isolated.
2. server2 starts; it will attempt to connect to server3, which is not
running. So server2 will sit there isolated.
3. server3 starts; it has no initialServers list so attempts no connects. So
server3 will sit there isolated.
The described setup is weaker than it needs to be as listing just one server
means the listed server is a potential point of weakness. As a matter of
trivia, it is interesting to point out that you could bring a fourth server
online temporarily that lists all three servers. Once it makes the
introductions and all servers learn of each other, you could shut it down again.
The above setup is easily fixable via better configuration. If server3 listed
both server1 and server2 in its initialServers list, rather than listing
nothing at all, then all servers would fully discover each other regardless of
startup order; assuming all three servers did eventually start.
THREE SERVERS OR LESS
In a three sever scenario, I recommend simply having all three servers list all
three servers.
server1/conf/multipoint.properties
initialServers = server1, server2, server3
server2/conf/multipoint.properties
initialServers = server1, server2, server3
server3/conf/multipoint.properties
initialServers = server1, server2, server3
There's no harm to listing yourself, it gives you one clean list to maintain
and it will work even if you decide not to start one of the three servers.
FOUR OR MORE
In a scenario of four or more, I recommend picking at least to servers and
focus on always keeping at least one of them running. Lets refer to them as
"root" servers for simplicity sake. Root server1 would list root server2 so
they would always be linked to each other regardless of start order or if one
of them went down. All other servers would simply list the root servers
(server1, server2) in their initialServers list. As long as at least one root
server (server1 or server2) was running, you can bring other servers on and
offline at will and always have a fully connected graph.
Of course all servers once running and connected will have a full list of all
other servers in the network, so if at any time the "root" servers weren't
around to make initial introductions to new servers wanting to join the network
it would be no trouble. At that point you can simply pick any other server to
do the introductions for the new servers joining. So these "root" servers are
no real point of failure in function, but only of convenience.
-David
