path: root/doc/book/src/Using-Broker-Federation.xml

<?xml version="1.0" encoding="utf-8"?>
<!--
 
 Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file
 distributed with this work for additional information
 regarding copyright ownership.  The ASF licenses this file
 to you under the Apache License, Version 2.0 (the
 "License"); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at
 
   http://www.apache.org/licenses/LICENSE-2.0
 
 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
 
-->

<section id="chap-Messaging_User_Guide-Broker_Federation">
	<title>Broker Federation</title>
	 <para>
		<firstterm>Broker Federation</firstterm> allows messaging networks to be defined by creating <firstterm>message routes</firstterm>, in which messages in one broker (the <firstterm>source broker</firstterm>) are automatically routed to another broker (the <firstterm>destination broker</firstterm>). These routes may be defined between exchanges in the two brokers (the <firstterm>source exchange</firstterm> and the <firstterm>destination exchange</firstterm>), or from a queue in the source broker (the <firstterm>source queue</firstterm>) to an exchange in the destination broker. Message routes are unidirectional; when bidirectional flow is needed, one route is created in each direction. Routes can be durable or transient. A durable route survives broker restarts, restoring a route as soon as both the source broker and the destination are available. If the connection to a destination is lost, messages associated with a durable route continue to accumulate on the source, so they can be retrieved when the connection is reestablished.
	</para>
	 <para>
		Broker Federation can be used to build large messaging networks, with many brokers, one route at a time. If network connectivity permits, an entire distributed messaging network can be configured from a single location. The rules used for routing can be changed dynamically as servers change, responsibilities change, at different times of day, or to reflect other changing conditions.
	</para>
	 <para>
		Broker Federation is useful in a wide variety of scenarios. Some of these have to do with functional organization; for instance, brokers may be organized by geography, service type, or priority. Here are some use cases for federation: 
		<itemizedlist>
			<listitem>
				<para>
					Geography: Customer requests may be routed to a processing location close to the customer.
				</para>

			</listitem>
			 <listitem>
				<para>
					Service Type: High value customers may be routed to more responsive servers.
				</para>

			</listitem>
			 <listitem>
				<para>
					Load balancing: Routing among brokers may be changed dynamically to account for changes in actual or anticipated load.
				</para>

			</listitem>
			 <listitem>
				<para>
					High Availability: Routing may be changed to a new broker if an existing broker becomes unavailable.
				</para>

			</listitem>
			 <listitem>
				<para>
					WAN Connectivity: Federated routes may connect disparate locations across a wide area network, while clients connect to brokers on their own local area network. Each broker can provide persistent queues that can hold messages even if there are gaps in WAN connectivity.
				</para>

			</listitem>
			 <listitem>
				<para>
					Functional Organization: The flow of messages among software subsystems can be configured to mirror the logical structure of a distributed application.
				</para>

			</listitem>
			 <listitem>
				<para>
					Replicated Exchanges: High-function exchanges like the XML exchange can be replicated to scale performance.
				</para>

			</listitem>
			 <listitem>
				<para>
					Interdepartmental Workflow: The flow of messages among brokers can be configured to mirror interdepartmental workflow at an organization.
				</para>

			</listitem>

		</itemizedlist>

	</para>
	 <section id="sect-Messaging_User_Guide-Broker_Federation-Message_Routes">
		<title>Message Routes</title>
		 <para>
			Broker Federation is done by creating message routes. The destination for a route is always an exchange on the destination broker. By default, a message route is created by configuring the destination broker, which then contacts the source broker to subscribe to the source queue. This is called a <firstterm>pull route</firstterm>. It is also possible to create a route by configuring the source broker, which then contacts the destination broker in order to send messages. This is called a <firstterm>push route</firstterm>, and is particularly useful when the destination broker may not be available at the time the messaging route is configured, or when a large number of routes are created with the same destination exchange.
		</para>
		 <para>
			The source for a route can be either an exchange or a queue on the source broker. If a route is between two exchanges, the routing criteria can be given explicitly, or the bindings of the destination exchange can be used to determine the routing criteria. To support this functionality, there are three kinds of message routes: queue routes, exchange routes, and dynamic exchange routes.
		</para>
		 <section id="sect-Messaging_User_Guide-Message_Routes-Queue_Routes">
			<title>Queue Routes</title>
			 <para>
				<firstterm>Queue Routes</firstterm> route all messages from a source queue to a destination exchange. If message acknowledgement is enabled, messages are removed from the queue when they have been received by the destination exchange; if message acknowledgement is off, messages are removed from the queue when sent.
			</para>

		</section>
		
		 <section id="sect-Messaging_User_Guide-Message_Routes-Exchange_Routes">
			<title>Exchange Routes</title>
			 <para>
				<firstterm>Exchange routes</firstterm> route messages from a source exchange to a destination exchange, using a binding key (which is optional for a fanout exchange).
			</para>
			 <para>
				Internally, creating an exchange route creates a private queue (auto-delete, exclusive) on the source broker to hold messages that are to be routed to the destination broker, binds this private queue to the source broker exchange, and subscribes the destination broker to the queue.
			</para>

		</section>
		
		 <section id="sect-Messaging_User_Guide-Message_Routes-Dynamic_Exchange_Routes">
			<title>Dynamic Exchange Routes</title>
			 <para>
				Dynamic exchange routes allow a client to create bindings to an exchange on one broker, and receive messages that satisfy the conditions of these bindings not only from the exchange to which the client created the binding, but also from other exchanges that are connected to it using dynamic exchange routes. If the client modifies the bindings for a given exchange, they are also modified for dynamic exchange routes associated with that exchange.
			</para>
			 <para>
				<firstterm>Dynamic exchange routes</firstterm> apply all the bindings of a destination exchange to a source exchange, so that any message that would match one of these bindings is routed to the destination exchange. If bindings are added or removed from the destination exchange, these changes are reflected in the dynamic exchange route -- when the destination broker creates a binding with a given binding key, this is reflected in the route, and when the destination broker drops a binding with a binding key, the route no longer incurs the overhead of transferring messages that match the binding key among brokers. If two exchanges have dynamic exchange routes to each other, then all bindings in each exchange are reflected in the dynamic exchange route of the other. In a dynamic exchange route, the source and destination exchanges must have the same exchange type, and they must have the same name; for instance, if the source exchange is a direct exchange, the destination exchange must also be a direct exchange, and the names must match.
			</para>
			 <para>
				Internally, dynamic exchange routes are implemented in the same way as exchange routes, except that the bindings used to implement dynamic exchange routes are modified if the bindings in the destination exchange change.
			</para>
			 <para>
				A dynamic exchange route is always a pull route. It can never be a push route.
			</para>

		</section>
		

	</section>
	
	 <section id="sect-Messaging_User_Guide-Broker_Federation-Federation_Topologies">
		<title>Federation Topologies</title>
		 <para>
			A federated network is generally a tree, star, or line, using bidirectional links (implemented as a pair of unidirectional links) between any two brokers. A ring topology is also possible, if only unidirectional links are used.
		</para>
		 <para>
			Every message transfer takes time. For better performance, you should minimize the number of brokers between the message origin and final destination. In most cases, tree or star topologies do this best.
		</para>
		 <para>
			For any pair of nodes A,B in a federated network, there should be only one path from A to B. If there is more than one path, message loops can cause duplicate message transmission and flood the federated network. The topologies discussed above do not have message loops. A ring topology with bidirectional links is one example of a topology that does cause this problem, because a given broker can receive the same message from two different brokers. Mesh topologies can also cause this problem.
		</para>

	</section>
	
	 <section id="sect-Messaging_User_Guide-Broker_Federation-Federation_among_High_Availability_Message_Clusters">
		<title>Federation among High Availability Message Clusters</title>
		 <para>
			Federation is generally used together with High Availability Message Clusters, using clusters to provide high availability on each LAN, and federation to route messages among the clusters. Because message state is replicated within a cluster, it makes little sense to define message routes between brokers in the same cluster.
		</para>
		 <para>
			To create a message route between two clusters, simply create a route between any one broker in the first cluster and any one broker in the second cluster. Each broker in a given cluster can use message routes defined for another broker in the same cluster. If the broker for which a message route is defined should fail, another broker in the same cluster can restore the message route.
		</para>

	</section>
	
	 <section id="sect-Messaging_User_Guide-Broker_Federation-The_qpid_route_Utility">
		<title>The qpid-route Utility</title>
		 <para>
			<command>qpid-route</command> is a command line utility used to configure federated networks of brokers and to view the status and topology of networks. It can be used to configure routes among any brokers that <command>qpid-route</command> can connect to.
		</para>
		 <para>
			The syntax of <command>qpid-route</command> is as follows:
		</para>
		 
<screen>
qpid-route [OPTIONS] dynamic add &#60;dest-broker&#62; &#60;src-broker&#62; &#60;exchange&#62; 
qpid-route [OPTIONS] dynamic del &#60;dest-broker&#62; &#60;src-broker&#62; &#60;exchange&#62;

qpid-route [OPTIONS] route add &#60;dest-broker&#62; &#60;src-broker&#62; &#60;exchange&#62; &#60;routing-key&#62; 
qpid-route [OPTIONS] route del &#60;dest-broker&#62; &#60;src-broker&#62; &#60;exchange&#62; &#60;routing-key&#62;

qpid-route [OPTIONS] queue add &#60;dest-broker&#62; &#60;src-broker&#62; &#60;dest-exchange&#62;  &#60;src-queue&#62;
qpid-route [OPTIONS] queue del &#60;dest-broker&#62; &#60;src-broker&#62; &#60;dest-exchange&#62;  &#60;src-queue&#62;

qpid-route [OPTIONS] list  [&#60;broker&#62;]
qpid-route [OPTIONS] flush [&#60;broker&#62;]    
qpid-route [OPTIONS] map   [&#60;broker&#62;]

<!--          qpid-route [OPTIONS] add connection &lt;dest-broker&gt; &lt;src-broker&gt;
qpid-route [OPTIONS] del connection &lt;dest-broker&gt; &lt;src-broker&gt;          -->
qpid-route [OPTIONS] list connections [&#60;broker&#62;]
</screen>
		 <para>
			The syntax for <command>broker</command>, <command>dest-broker</command>, and <command>src-broker</command> is as follows:
		</para>
		 
<screen>
[username/password@] hostname | ip-address [:&#60;port&#62;]
</screen>
		 <para>
			The following are all valid examples of the above syntax: <command>localhost</command>, <command>10.1.1.7:10000</command>, <command>broker-host:10000</command>, <command>guest/guest@localhost</command>.
		</para>
		 <para>
			These are the options for <command>qpid-route</command>:
		</para>
		 <table frame="all" id="tabl-Messaging_User_Guide-The_qpid_route_Utility-qpid_route_options">
			<title><command>qpid-route</command> options</title>
			 <tgroup align="left" cols="2" colsep="1" rowsep="1">
				<colspec colname="c1"></colspec>
				 <colspec colname="c2"></colspec>
				 <!--           			<thead>
				<row>
					<entry align="center" nameend="c2" namest="c1">
						Options for using <command>qpid-route</command> to Manage Federation
					</entry>
				</row>
			</thead>
           --> <tbody>
					<row>
						<entry>
							<command>-v</command>
						</entry>
						 <entry>
							Verbose output.
						</entry>

					</row>
					 <row>
						<entry>
							<command>-q</command>
						</entry>
						 <entry>
							Quiet output, will not print duplicate warnings.
						</entry>

					</row>
					 <row>
						<entry>
							<command>-d</command>
						</entry>
						 <entry>
							Make the route durable.
						</entry>

					</row>
					 <!--         
					<row>
						<entry>
							<command>-e</command>
						</entry>
						<entry>
							Delete link after deleting the last route on the link. 
						</entry>
					</row>          --> <row>
						<entry>
							<command> --timeout N</command>
						</entry>
						 <entry>
							Maximum time to wait when qpid-route connects to a broker, in seconds. Default is 10 seconds.
						</entry>

					</row>
					 <row>
						<entry>
							<command>--ack N</command>
						</entry>
						 <entry>
							Acknowledge transfers of routed messages in batches of N. Default is 0 (no acknowledgements). Setting to 1 or greater enables acknowledgements; when using acknowledgements, values of N greater than 1 can significnantly improve performance, especially if there is significant network latency between the two brokers.
						</entry>

					</row>
					 <row>
						<entry>
							<command>-s [ --src-local ]</command>
						</entry>
						 <entry>
							Configure the route in the source broker (create a push route).
						</entry>

					</row>
					 <row>
						<entry>
							<command>-t &#60;transport&#62; [ --transport &#60;transport&#62;]</command>
						</entry>
						 <entry>
							Transport protocol to be used for the route. 
							<itemizedlist>
								<listitem>
									<para>
										tcp (default)
									</para>

								</listitem>
								 <listitem>
									<para>
										ssl
									</para>

								</listitem>
								 <listitem>
									<para>
										rdma
									</para>

								</listitem>

							</itemizedlist>

						</entry>

					</row>

				</tbody>

			</tgroup>

		</table>
		 <section id="sect-Messaging_User_Guide-The_qpid_route_Utility-Creating_and_Deleting_Queue_Routes">
			<title>Creating and Deleting Queue Routes</title>
			 <para>
				The syntax for creating and deleting queue routes is as follows:
			</para>
			 
<screen>
qpid-route [OPTIONS] queue add &#60;dest-broker&#62; &#60;src-broker&#62; &#60;dest-exchange&#62; &#60;src-queue&#62;
qpid-route [OPTIONS] queue del &#60;dest-broker&#62; &#60;src-broker&#62; &#60;dest-exchange&#62; &#60;src-queue&#62;
</screen>
			 <para>
				For instance, the following creates a queue route that routes all messages from the queue named <command>public</command> on the source broker <command>localhost:10002</command> to the <command>amq.fanout</command> exchange on the destination broker <command>localhost:10001</command>:
			</para>
			 
<screen>
$ qpid-route queue add localhost:10001 localhost:10002 amq.fanout public
</screen>
			 <para>
				If the <command>-d</command> option is specified, this queue route is persistent, and will be restored if one or both of the brokers is restarted:
			</para>
			 
<screen>
$ qpid-route -d queue add localhost:10001 localhost:10002 amq.fanout public
</screen>
			 <para>
				The <command>del</command> command takes the same arguments as the <command>add</command> command. The following command deletes the queue route described above:
			</para>
			 
<screen>
$ qpid-route queue del localhost:10001 localhost:10002 amq.fanout public
</screen>

		</section>
		
		 <section id="sect-Messaging_User_Guide-The_qpid_route_Utility-Creating_and_Deleting_Exchange_Routes">
			<title>Creating and Deleting Exchange Routes</title>
			 <para>
				The syntax for creating and deleting exchange routes is as follows:
			</para>
			 
<screen>
qpid-route [OPTIONS] route add &#60;dest-broker&#62; &#60;src-broker&#62; &#60;exchange&#62; &#60;routing-key&#62; 
qpid-route [OPTIONS] route del &#60;dest-broker&#62; &#60;src-broker&#62; &#60;exchange&#62; &#60;routing-key&#62;
qpid-route [OPTIONS] flush [&#60;broker&#62;]
</screen>
			 <para>
				For instance, the following creates an exchange route that routes messages that match the binding key <command>global.#</command> from the <command>amq.topic</command> exchange on the source broker <command>localhost:10002</command> to the <command>amq.topic</command> exchange on the destination broker <command>localhost:10001</command>:
			</para>
			 
<screen>
$ qpid-route route add localhost:10001 localhost:10002 amq.topic global.#
</screen>
			 <para>
				In many applications, messages published to the destination exchange should also be routed to the source exchange. This is accomplished by creating a second exchange route, reversing the roles of the two exchanges:
			</para>
			 
<screen>
$ qpid-route route add localhost:10002 localhost:10001 amq.topic global.#
</screen>
			 <para>
				If the <command>-d</command> option is specified, the exchange route is persistent, and will be restored if one or both of the brokers is restarted:
			</para>
			 
<screen>
$ qpid-route -d route add localhost:10001 localhost:10002 amq.fanout public
</screen>
			 <para>
				The <command>del</command> command takes the same arguments as the <command>add</command> command. The following command deletes the first exchange route described above:
			</para>
			 
<screen>
$ qpid-route route del localhost:10001 localhost:10002 amq.topic global.#
</screen>

		</section>
		
		 <section id="sect-Messaging_User_Guide-The_qpid_route_Utility-Deleting_all_routes_for_a_broker">
			<title>Deleting all routes for a broker</title>
			 <para>
				Use the <command>flush</command> command to delete all routes for a given broker:
			</para>
			 
<screen>
qpid-route [OPTIONS] flush [&#60;broker&#62;]
</screen>
			 <para>
				For instance, the following command deletes all routes for the broker <command>localhost:10001</command>:
			</para>
			 
<screen>
$ qpid-route flush localhost:10001
</screen>

		</section>
		
		 <section id="sect-Messaging_User_Guide-The_qpid_route_Utility-Creating_and_Deleting_Dynamic_Exchange_Routes">
			<title>Creating and Deleting Dynamic Exchange Routes</title>
			 <para>
				The syntax for creating and deleting dynamic exchange routes is as follows:
			</para>
			 
<screen>
qpid-route [OPTIONS] dynamic add &#60;dest-broker&#62; &#60;src-broker&#62; &#60;exchange&#62; 
qpid-route [OPTIONS] dynamic del &#60;dest-broker&#62; &#60;src-broker&#62; &#60;exchange&#62;
</screen>
			 <para>
				In the following examples, we will route messages from a topic exchange. We will create a new topic exchange and federate it so that we are not affected by other all clients that use the built-in <command>amq.topic</command> exchange. The following commands create a new topic exchange on each of two brokers:
			</para>
			 
<screen>
$ qpid-config -a localhost:10003 add exchange topic fed.topic
$ qpid-config -a localhost:10004 add exchange topic fed.topic
</screen>
			 <para>
				Now let&#39;s create a dynamic exchange route that routes messages from the <command>fed.topic</command> exchange on the source broker <command>localhost:10004</command> to the <command>fed.topic</command> exchange on the destination broker <command>localhost:10003</command> if they match any binding on the destination broker&#39;s <command>fed.topic</command> exchange:
			</para>
			 
<screen>
$ qpid-route dynamic add localhost:10003 localhost:10004 fed.topic
</screen>
			 <para>
				Internally, this creates a private autodelete queue on the source broker, and binds that queue to the <command>fed.topic</command> exchange on the source broker, using each binding associated with the <command>fed.topic</command> exchange on the destination broker.
			</para>
			 <para>
				In many applications, messages published to the destination exchange should also be routed to the source exchange. This is accomplished by creating a second dynamic exchange route, reversing the roles of the two exchanges:
			</para>
			 
<screen>
$ qpid-route dynamic add localhost:10004 localhost:10003 fed.topic
</screen>
			 <para>
				If the <command>-d</command> option is specified, the exchange route is persistent, and will be restored if one or both of the brokers is restarted:
			</para>
			 
<screen>
$ qpid-route -d dynamic add localhost:10004 localhost:10003 fed.topic
</screen>
			 <para>
				When an exchange route is durable, the private queue used to store messages for the route on the source exchange is also durable. If the connection between the brokers is lost, messages for the destination exchange continue to accumulate until it can be restored.
			</para>
			 <para>
				The <command>del</command> command takes the same arguments as the <command>add</command> command. The following command deletes the first exchange route described above:
			</para>
			 
<screen>
$ qpid-route dynamic del localhost:10004 localhost:10003 fed.topic
</screen>
			 <para>
				Internally, this deletes the bindings on the source exchange for the the private queues associated with the message route.
			</para>

		</section>
		
		 <section id="sect-Messaging_User_Guide-The_qpid_route_Utility-Viewing_Routes">
			<title>Viewing Routes</title>
			 <para>
				The <command>route list</command> command shows the routes associated with an individual broker. For instance, suppose we have created the following two routes:
			</para>
			 
<screen>
$ qpid-route dynamic add localhost:10003 localhost:10004 fed.topic
$ qpid-route dynamic add localhost:10004 localhost:10003 fed.topic
</screen>
			 <para>
				We can now use <command>route list</command> to show all routes for the broker <command>localhost:10003</command>:
			</para>
			 
<screen>
$ qpid-route route list localhost:10003
localhost:10003 localhost:10004 fed.topic &#60;dynamic&#62;
</screen>
			 <para>
				Note that this shows only one of the two routes we created, the route for which <command>localhost:10003</command> is a destination. If we want to see the route for which <command>localhost:10004</command> is a destination, we need to do another route list:
			</para>
			 
<screen>
$ qpid-route route list localhost:10004
localhost:10004 localhost:10003 fed.topic &#60;dynamic&#62;
</screen>
			 <para>
				The <command>route map</command> command shows all routes associated with a broker, and recursively displays all routes for brokers involved in federation relationships with the given broker. For instance, here is the output for the two brokers configured above:
			</para>
			 
<screen>
$ qpid-route route map localhost:10003

Finding Linked Brokers:
    localhost:10003... Ok
    localhost:10004... Ok

Dynamic Routes:

  Exchange fed.topic:
    localhost:10004 &#60;=&#62; localhost:10003

Static Routes:
  none found
</screen>
			 <para>
				Note that the two dynamic exchange links are displayed as though they were one bidirectional link. The <command>route map</command> command is particularly helpful for larger, more complex networks. Let&#39;s configure a somewhat more complex network with 16 dynamic exchange routes:
			</para>
			 
<screen>
qpid-route dynamic add localhost:10001 localhost:10002 fed.topic
qpid-route dynamic add localhost:10002 localhost:10001 fed.topic

qpid-route dynamic add localhost:10003 localhost:10002 fed.topic
qpid-route dynamic add localhost:10002 localhost:10003 fed.topic

qpid-route dynamic add localhost:10004 localhost:10002 fed.topic
qpid-route dynamic add localhost:10002 localhost:10004 fed.topic

qpid-route dynamic add localhost:10002 localhost:10005 fed.topic
qpid-route dynamic add localhost:10005 localhost:10002 fed.topic

qpid-route dynamic add localhost:10005 localhost:10006 fed.topic
qpid-route dynamic add localhost:10006 localhost:10005 fed.topic

qpid-route dynamic add localhost:10006 localhost:10007 fed.topic
qpid-route dynamic add localhost:10007 localhost:10006 fed.topic

qpid-route dynamic add localhost:10006 localhost:10008 fed.topic
qpid-route dynamic add localhost:10008 localhost:10006 fed.topic
</screen>
			 <para>
				Now we can use <command>route map</command> starting with any one broker, and see the entire network:
			</para>
			 
<screen>
$ ./qpid-route route map localhost:10001

Finding Linked Brokers:
    localhost:10001... Ok
    localhost:10002... Ok
    localhost:10003... Ok
    localhost:10004... Ok
    localhost:10005... Ok
    localhost:10006... Ok
    localhost:10007... Ok
    localhost:10008... Ok

Dynamic Routes:

  Exchange fed.topic:
    localhost:10002 &#60;=&#62; localhost:10001
    localhost:10003 &#60;=&#62; localhost:10002
    localhost:10004 &#60;=&#62; localhost:10002
    localhost:10005 &#60;=&#62; localhost:10002
    localhost:10006 &#60;=&#62; localhost:10005
    localhost:10007 &#60;=&#62; localhost:10006
    localhost:10008 &#60;=&#62; localhost:10006

Static Routes:
  none found
</screen>

		</section>
		
		 <section id="sect-Messaging_User_Guide-The_qpid_route_Utility-Resilient_Connections">
			<title>Resilient Connections</title>
			 <para>
				When a broker route is created, or when a durable broker route is restored after broker restart, a connection is created between the source broker and the destination broker. The connections used between brokers are called <firstterm>resilient connections</firstterm>; if the connection fails due to a communication error, it attempts to reconnect. The retry interval begins at 2 seconds and, as more attempts are made, grows to 64 seconds, and continues to retry every 64 seconds thereafter. If the connection fails due to an authentication problem, it will not continue to retry.
			</para>
			 <para>
				The command <command>list connections</command> can be used to show the resilient connections for a broker:
			</para>
			 
<screen>
$ qpid-route list connections localhost:10001

Host            Port    Transport Durable  State             Last Error
=============================================================================
localhost       10002   tcp          N     Operational       
localhost       10003   tcp          N     Operational       
localhost       10009   tcp          N     Waiting           Connection refused
</screen>
			 <para>
				In the above output, <command>Last Error</command> contains the string representation of the last connection error received for the connection. <command>State</command> represents the state of the connection, and may be one of the following values:
			</para>
			 <table id="tabl-Messaging_User_Guide-Resilient_Connections-State_values_in_qpid_route_list_connections">
				<title>State values in <command>$ qpid-route list connections</command></title>
				 <tgroup align="left" cols="2" colsep="1" rowsep="1">
					<tbody>
						<row>
							<entry>
								Waiting
							</entry>
							 <entry>
								Waiting before attempting to reconnect.
							</entry>

						</row>
						 <row>
							<entry>
								Connecting
							</entry>
							 <entry>
								Attempting to establish the connection.
							</entry>

						</row>
						 <row>
							<entry>
								Operational
							</entry>
							 <entry>
								The connection has been established and can be used.
							</entry>

						</row>
						 <row>
							<entry>
								Failed
							</entry>
							 <entry>
								The connection failed and will not retry (usually because authentication failed).
							</entry>

						</row>
						 <row>
							<entry>
								Closed
							</entry>
							 <entry>
								The connection has been closed and will soon be deleted.
							</entry>

						</row>
						 <row>
							<entry>
								Passive
							</entry>
							 <entry>
								If a cluster is federated to another cluster, only one of the nodes has an actual connection to remote node. Other nodes in the cluster have a passive connection.
							</entry>

						</row>

					</tbody>

				</tgroup>

			</table>

		</section>
		

	</section>
	

</section>