You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by db...@apache.org on 2011/10/27 22:28:17 UTC
svn commit: r1190000 - in /openejb/site/trunk/content:
multipoint-considerations.mdtext multipoint-discovery.mdtext
Author: dblevins
Date: Thu Oct 27 20:28:17 2011
New Revision: 1190000
URL: http://svn.apache.org/viewvc?rev=1190000&view=rev
Log:
Had some leftover text that needed to be yanked
Modified:
openejb/site/trunk/content/multipoint-considerations.mdtext
openejb/site/trunk/content/multipoint-discovery.mdtext
Modified: openejb/site/trunk/content/multipoint-considerations.mdtext
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/multipoint-considerations.mdtext?rev=1190000&r1=1189999&r2=1190000&view=diff
==============================================================================
--- openejb/site/trunk/content/multipoint-considerations.mdtext (original)
+++ openejb/site/trunk/content/multipoint-considerations.mdtext Thu Oct 27 20:28:17 2011
@@ -4,11 +4,11 @@ Title: Multipoint Considerations
The general disadvantage of this topology is the number of connections
required. The number of connections for the network of servers is equal to
-"(n * n - n) / 2 ", where n is the number of servers. For example, with 5
+`(n * n - n) / 2`, where n is the number of servers. For example, with 5
servers you need 10 connections, with 10 servers you need 45 connections,
and with 50 servers you need 1225 connections. This is of course the
number of connections across the entire network, each individual server
-only needs "n - 1" connections.
+only needs `n - 1` connections.
The handling of these sockets is all asynchronous Java NIO code which
allows the server to handle many connections (all of them) with one thread.
@@ -24,143 +24,3 @@ happens both servers will detect the ext
connections will be dropped and one will be kept. In practice this race
condition rarely happens and can be avoided almost entirely by fanning out
server startup by as little as 100 milliseconds.
-
-# Multipoint Configuration Recommendations
-
-As mentioned above the `initialServers` is only used for bootstrapping
-the multipoint network. Once running, all servers will dynamically
-establish direct connections with each other and there is no single point
-of failure.
-
-However to ensure that the bootstrapping process can occur successfully,
-the `initialServers` property of the `conf/multipoint.properties` file
-must be set carefully and with a specific server start order in mind. Each
-server consults its `initialServers` list exactly once in the
-bootstrapping phase at startup, after that time connections are made
-dynamically.
-
-This means that at least one of the servers listed in `initialServers`
-must already be running when the server starts or the server might never
-become introduced and connected to all the other servers in the network.
-
-## Failed scenario (background)
-
-As an example of a failed scenario, imagine there are three servers;
-server1, server2, server3. They are setup only to point to the server in
-front of them making a chain:
-
- * server1; initialServers = server2
- * server2; initialServers = server3
- * server3; initialServers = <blank>
-
-Which is essentially server1 -> server2 -> server3. This scenario could
-work, but they servers would have to be started in exactly the opposite
-order:
-
- # server3 starts
- # server2 starts
- #* static: connect to server3
- # server1 starts
- #* static: connect to server2
- #* dynamic: connect to server3
-
-At this point all servers would be fully connected. But the above setup is
-flawed and could easily fail. The first flaw is server3 lists nothing in
-its `initialServers` list, so if it were restarted it would leave the
-multipoint network and not know how to get back in.
-
-The second flaw is if you started them in any other order, you would also
-not get a fully connected multipoint network. Say the servers were started
-in "front" order:
-
- # server1 starts
- #* static: connect to server2 - failed, server2 not started.
- # server2 starts
- #* static: connect to server3 - failed, server3 not started.
- # server3 starts
- #* no connection attempts, initialServers list is empty.
-
-After startup completes, all servers will be completely isolated and
-failover will not work. The described setup is weaker than it needs to be.
-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.
-
-## Bootstrapping Three Servers or Less
-
-In a three sever scenario, we 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 a server listing itself. It gives you one clean list to
-maintain and it will work even if you decide not to start one of the three
-servers.
-
-## Bootstrapping Four Servers or More
-
-In a scenario of four or more, we 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.
-
- * server1/conf/multipoint.properties
- ** initialServers = server2
- * server2/conf/multipoint.properties
- ** initialServers = server1
-
-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. Server1 could
-be shutdown and reconnect on startup to the full multipoint network through
-server2, and vice versa.
-
-All other servers would simply list the root servers (server1, server2) in
-their initialServers list.
-
- * server3/conf/multipoint.properties
- ** initialServers = server1, server2
- * server4/conf/multipoint.properties
- ** initialServers = server1, server2
- * serverN/conf/multipoint.properties
- ** initialServers = server1, server2
-
-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 it would be no
-trouble. It's possible to reconfigure new servers to point at any other
-server in the network as all servers will have the full list. So these
-"root" servers are no real point of failure in function, but only of
-convenience.
-
-## Command line overrides
-
-Always remember that any property in a conf/<server-service>.properties
-file can be overridden on the command line or via system properties. So it
-is possible easily set the initialServers list in startup scripts.
-
-A bash example might look something like:
-
- !/bin/bash
-
- OPENEJB_HOME=/opt/openejb-3.1.3
- INITIAL_LIST=$(cat /some/shared/directory/our_initial_servers.txt)
-
- $OPENEJB_HOME/bin/openejb start -Dmultipoint.initialServers=$INITIAL_LIST
-
-
Modified: openejb/site/trunk/content/multipoint-discovery.mdtext
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/multipoint-discovery.mdtext?rev=1190000&r1=1189999&r2=1190000&view=diff
==============================================================================
--- openejb/site/trunk/content/multipoint-discovery.mdtext (original)
+++ openejb/site/trunk/content/multipoint-discovery.mdtext Thu Oct 27 20:28:17 2011
@@ -26,7 +26,6 @@ list to bootstrap getting the more valua
# Server Configuration
-
In the server this list can be specified via the
`conf/multipoint.properties` file like so:
@@ -44,7 +43,6 @@ servers on the network. Only one of the
running when this server starts up -- it is not required to list all
servers in the network.
-<a name="Failover-ClientConfiguration"></a>
# Client Configuration
Configuration in the client is similar, but note that EJB clients do not
@@ -57,170 +55,17 @@ the multipoint port. The server list is
p.put(Context.PROVIDER_URL, "failover:ejbd://192.168.1.20:4201,ejbd://192.168.1.30:4201");
InitialContext remoteContext = new InitialContext(p);
-
-## Considerations
-
-### Network size
-
-The general disadvantage of this topology is the number of connections
-required. The number of connections for the network of servers is equal to
-"(n * n - n) / 2 ", where n is the number of servers. For example, with 5
-servers you need 10 connections, with 10 servers you need 45 connections,
-and with 50 servers you need 1225 connections. This is of course the
-number of connections across the entire network, each individual server
-only needs "n - 1" connections.
-
-The handling of these sockets is all asynchronous Java NIO code which
-allows the server to handle many connections (all of them) with one thread.
- From a pure threading perspective, the option is extremely efficient with
-just one thread to listen and broadcast to many peers.
-
-### Double connect
-
-It is possible in this process that two servers learn of each other at the
-same time and each attempts to connect to the other simultaneously,
-resulting in two connections between the same two servers. When this
-happens both servers will detect the extra connection and one of the
-connections will be dropped and one will be kept. In practice this race
-condition rarely happens and can be avoided almost entirely by fanning out
-server startup by as little as 100 milliseconds.
-
-# Multipoint Configuration Recommendations
-
-As mentioned above the `initialServers` is only used for bootstrapping
-the multipoint network. Once running, all servers will dynamically
-establish direct connections with each other and there is no single point
-of failure.
-
-However to ensure that the bootstrapping process can occur successfully,
-the `initialServers` property of the `conf/multipoint.properties` file
-must be set carefully and with a specific server start order in mind. Each
-server consults its `initialServers` list exactly once in the
-bootstrapping phase at startup, after that time connections are made
-dynamically.
-
-This means that at least one of the servers listed in `initialServers`
-must already be running when the server starts or the server might never
-become introduced and connected to all the other servers in the network.
-
-## Failed scenario (background)
-
-As an example of a failed scenario, imagine there are three servers;
-server1, server2, server3. They are setup only to point to the server in
-front of them making a chain:
-
- * server1; initialServers = server2
- * server2; initialServers = server3
- * server3; initialServers = <blank>
-
-Which is essentially server1 -> server2 -> server3. This scenario could
-work, but they servers would have to be started in exactly the opposite
-order:
-
- # server3 starts
- # server2 starts
- #* static: connect to server3
- # server1 starts
- #* static: connect to server2
- #* dynamic: connect to server3
-
-At this point all servers would be fully connected. But the above setup is
-flawed and could easily fail. The first flaw is server3 lists nothing in
-its `initialServers` list, so if it were restarted it would leave the
-multipoint network and not know how to get back in.
-
-The second flaw is if you started them in any other order, you would also
-not get a fully connected multipoint network. Say the servers were started
-in "front" order:
-
- # server1 starts
- #* static: connect to server2 - failed, server2 not started.
- # server2 starts
- #* static: connect to server3 - failed, server3 not started.
- # server3 starts
- #* no connection attempts, initialServers list is empty.
-
-After startup completes, all servers will be completely isolated and
-failover will not work. The described setup is weaker than it needs to be.
-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.
-
-## Bootstrapping Three Servers or Less
-
-In a three sever scenario, we 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 a server listing itself. It gives you one clean list to
-maintain and it will work even if you decide not to start one of the three
-servers.
-
-## Bootstrapping Four Servers or More
-
-In a scenario of four or more, we 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.
-
- * server1/conf/multipoint.properties
- ** initialServers = server2
- * server2/conf/multipoint.properties
- ** initialServers = server1
-
-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. Server1 could
-be shutdown and reconnect on startup to the full multipoint network through
-server2, and vice versa.
-
-All other servers would simply list the root servers (server1, server2) in
-their initialServers list.
-
- * server3/conf/multipoint.properties
- ** initialServers = server1, server2
- * server4/conf/multipoint.properties
- ** initialServers = server1, server2
- * serverN/conf/multipoint.properties
- ** initialServers = server1, server2
-
-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 it would be no
-trouble. It's possible to reconfigure new servers to point at any other
-server in the network as all servers will have the full list. So these
-"root" servers are no real point of failure in function, but only of
-convenience.
-
-## Command line overrides
-
-Always remember that any property in a conf/<server-service>.properties
-file can be overridden on the command line or via system properties. So it
-is possible easily set the initialServers list in startup scripts.
-
-A bash example might look something like:
-
- !/bin/bash
+Failover can work entirely driven by the server, the client does not need
+to be configured to participate. A client can connect as usual to the server.
- OPENEJB_HOME=/opt/openejb-3.1.3
- INITIAL_LIST=$(cat /some/shared/directory/our_initial_servers.txt)
+ Properties p = new Properties();
+ p.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.RemoteInitialContextFactory");
+ p.put(Context.PROVIDER_URL, "ejbd://192.168.1.20:4201");
+ InitialContext remoteContext = new InitialContext(p);
- $OPENEJB_HOME/bin/openejb start -Dmultipoint.initialServers=$INITIAL_LIST
+If the server at `192.168.1.20:4201` supports failover, so will the client.
-
+In this scenario the list of servers used for failover is supplied entirely
+by the server at `192.168.1.20:4201`. The server could have aquired the list
+via multicast or multipoint (or both), but this detail is not visible to the
+client.