About
Red Hat AMQ Broker is a high-performance messaging system for highly scalable microservices and asynchronous messaging between different systems. It enables you to define different topologies to build simple or complex messaging solutions.
This cheat sheet includes the most common commands to install, deploy, administer, and operate a messaging system based on AMQ Broker. You’ll also get an overview of the most standard topologies that cover high availability, scalability, and failover: symmetric cluster with a replicated journal and symmetric cluster with the shared journal.
Download the Red Hat AMQ Broker Cheat Sheet and learn how to:
- Start a broker instance
- Install a broker as an operating system service
- Use XML inclusions to break the configuration into separate files
- Create and delete addresses and queues automatically, so you don't have to manage the address in the broker.xml file
- Send messages to a resource
- Consume messages from a resource
- Configure addresses and queues
- Work with the clustered message grouping feature
- Monitor brokers for problems and handle errors
- Manage users
- Encrypt passwords in configuration files
With Red Hat Developer cheat sheets, you get essential information right at your fingertips so you can work faster and smarter. Easily learn new technologies and coding concepts and quickly find the answers you need.
Excerpt
High availability and failover
AMQ Broker includes a failover feature based on the combined use of live and backup brokers. This feature requires you to define a connection for automatic client failover.
A client can receive information about all live and backup brokers so that the client can reconnect to the backup broker in the event of a connection failure. The backup broker then automatically recreates any sessions and consumers that existed on each connection before failover. This feature saves you from having to hand-code manual reconnection logic in your applications.
When a session is recreated on the backup, it lacks knowledge of messages already sent or acknowledged. Any in-flight sends or acknowledgments at the time of failover might also be lost. However, even without 100% transparent failover, it is simple to guarantee once and only once delivery, even in the case of failure, by using a combination of duplicate detection and retrying of transactions.
Client connection strings identify a connection string using the Core Protocol with the right values to enable high availability and failover from the client side. For example:
Single broker:
tcp://HOSTNAME1:61616?ha=true&reconnectAttempts=10Failover connection:
(tcp://HOSTNAME1:616161,tcp://HOSTNAME2:61616)?ha=true&reconnectAttempts=10
Every time a live broker shuts down, the backup instance will be promoted as lived instance to continue the service to producers and consumers and distribute the messages to other topology members. The backup instance could delegate the role back to the live instance as soon as it is ready. The following definition in the backup instance automates that life cycle:
<ha-policy>
<shared-store>
<slave>
<allow-failback>true</allow-failback>
</slave>
</shared-store>
</ha-policy>