Apache ActiveMQ ™ -- Run Broker
Running an ActiveMQ BrokerNote if you want to use an embedded broker then see This page describes how to run a broker using 4.x or later of ActiveMQ.Running the broker as a Unix ServiceSee the 
for details.Running the broker using the Java Service Wrapper ImplementationSee the  for details.Monitoring the brokerYou can monitor ActiveMQ using the
by pointing your browser atOr you can use the
support to view the running state of ActiveMQ.For more information see the file docs/WebConsole-README.txt in the distribution.See the source code (or WAR) of the
for an example of how to run the broker inside a web application using Spring.Whether its Apache Geronmio, JBoss 4, WebLogic 9 or some other J2EE 1.4 container you should be able to just reconfigure and then deploy the activemq-*.rar which is included in the binary distribution as a deployment unit in your app server. By default the rar is not configured to start an embedded broker. But by setting the brokerXmlConfig on the resource adapter configuration, the resource adapter will start an embedded broker.For more details see Running the broker from the source codeFrom the latest
of the code you can run a broker using the Running the broker from mavenYou can download and install the ActiveMQ Startup Maven Plugin via the following command if you are in a directory with a pom.xml. More detailed usage
mvn org.apache.activemq.tooling:maven-activemq-plugin:5.0-SNAPSHOT:run
You can also include it the pom and run it using:
mvn activemq:run
Handling JMS brokers going downA common requirement is that if the JMS broker goes down you want to automatically detect the failure and try to reconnect under the covers so that your application does not have to worry about reconnection.There is detailed docum briefly...Just change your connection URI in 4.x to
failover:tcp://host:port
And the JMS client will auto-reconnect to the broker if it is shutdown and restarted later on.
The Apache Software Foundation.
Apache ActiveMQ, ActiveMQ, Apache, the Apache feather logo, and the Apache ActiveMQ project logo are trademarks of The Apache Software Foundation.
All other marks mentioned may be trademarks or registered trademarks of their respective owners.RabbitMQ - Distributed RabbitMQ brokers
Distributed RabbitMQ brokers
AMQP and the other messaging protocols supported by RabbitMQ via
plug-ins (e.g. STOMP), are (of course) inherently distributed -
it is quite common for applications from multiple machines to
connect to a single broker, even across the internet.
Sometimes however it is necessary or desirable to make the
RabbitMQ broker itself distributed. There are three ways in
which to accomplish that: with clustering, with federation, and
using the shovel. This page explains the purpose of each
Note that you do not need to pick a single approach - you can
connect clusters together with federation, or the shovel, or both.
Clustering
connects multiple
machines together to form a single logical broker. Communication
is via Erlang message-passing, so all nodes in the cluster must
have the same Erlang cookie. The network links between machines
in a cluster must be reliable, and all machines in the
cluster must run the same versions of RabbitMQ and Erlang.
Virtual hosts, exchanges, users, and permissions are
automatically mirrored across all nodes in a cluster. Queues may
be located on a single node, or . A client connecting to any node in a
cluster can see all queues in the cluster, even if they are not
located on that node.
Typically you would use clustering for high availability and
increased throughput, with machines in a single location.
Federation
allows an exchange or
queue on one broker to receive messages published to an exchange
or queue on another (the brokers may be individual machines, or
clusters). Communication is via AMQP (with optional SSL), so for
two exchanges or queues to federate they must be granted
appropriate users and permissions.
Federated exchanges are connected with one way point-to-point
links. By default, messages will only be forwarded over a
federation link once, but this can be increased to allow for
more complex routing topologies. Some messages may not be
for if a message would not be routed to a
queue after reaching the federated exchange, it will not be
forwarded in the first place.
Federated queues are similarly connected with one way
point-to-point links. Messages will be moved between federated
queues an arbitrary number of times to follow the consumers.
Typically you would use federation to link brokers across the
internet for pub/sub messaging and work queueing.
The Shovel
Connecting brokers
is conceptually similar to connecting them with
federation. However, the shovel works at a lower level.
Whereas federation aims to provide opinionated distribution of
exchanges and queues, the shovel simply consumes messages from a
queue on one broker, and forwards them to an exchange on
Typically you would use the shovel to link brokers across the
internet when you need more control than federation provides.
can also be
useful for moving messages around in an ad-hoc manner on a
single broker.
Federation / Shovel
Clustering
Brokers are logically separate and may have different owners.
A cluster forms a single logical broker.
Brokers can run different versions of RabbitMQ and Erlang.
Nodes must run the same version of RabbitMQ, and frequently Erlang.
Brokers can be connected via unreliable WAN
links. Communication is via AMQP (optionally secured by
SSL), requiring appropriate users and permissions to be set up.
Brokers must be connected via reliable LAN
links. Communication is via Erlang internode messaging,
requiring a shared Erlang cookie.
Brokers can be connected in whatever topology you
arrange. Links can be one- or two-way.
All nodes connect to all other nodes in both directions.
Chooses Availability and Partition Tolerance (AP) from
Chooses Consistency and Partition Tolerance (CP)
from the .
Some exchanges in a broker may be federated while some may be local.
Clustering is all-or-nothing.
A client connecting to any broker can only see queues in that broker.
A client connecting to any node can see queues on all nodes.
Getting Help and Providing Feedback
If you have questions about the contents of this guide or
any other topic related to RabbitMQ, don't hesitate to ask them
Documentation feedback is also very welcome on the list. If you'd like to contribute an improvement
to the site, its source is .}