Chapter 1. Introduction
This guide describes the new features and changes to behavior in AMQ 7. If you have an existing AMQ 6 environment, this guide will help you to understand the differences in AMQ 7 so that you are prepared to configure new broker instances in AMQ 7.
1.1. When to Get Assistance Before Migrating
If you plan to migrate a production environment, you should seek further assistance and guidance from a Red Hat support representative. You can open a support case at https://access.redhat.com/support/.
1.2. Supported Migration Paths
You can use this guide to understand the configuration changes that might be required to create a AMQ Broker 7 configuration to which existing OpenWire JMS clients can connect.
This guide does not describe how to migrate the following features:
The message store
This guide provides information about configuration changes that will help you to configure a new AMQ 7 broker instance. Data, such as messages stored on the AMQ 6 broker, will not be migrated.
Clients (other than OpenWire JMS clients)
This guide helps you to configure a AMQ 7 broker instance to which existing OpenWire JMS clients can connect. For information about creating new clients that can connect to a AMQ 7 broker, see the client guides at the Red Hat Customer Portal.
1.3. Understanding the Important New Concepts in AMQ 7
Before learning about the specific configuration changes in each AMQ feature area, you should first understand the important conceptual differences between AMQ 6 and AMQ 7.
There are several key architectural differences in AMQ 7. In addition, a new message addressing and routing model has been implemented in this release.
1.3.1. Architectural Changes in AMQ 7
AMQ 7 offers key architectural changes for how incoming network connections are made to the broker, the message store, and the way in which brokers are deployed.
Transport Connector Changes for Incoming Connections
AMQ 6 used different types of transport connectors, such as TCP (synchronous) and Java NIO (non-blocking).
In AMQ 7, you no longer have to choose which transport type to use: all incoming network connections between entities in different virtual machines use Netty connections. Netty is a high-performance, low-level network library that allows network connections to be configured to use Java IO, Java NIO, TCP sockets, SSL/TLS, HTTP, and HTTPS.
Message Store and Paging Changes
The process by which the broker stores messages in memory and pages them to disk is different in AMQ 7.
AMQ 6 used KahaDB for a message store, which consists of both a message journal for fast, sequential message storing, and an index to retrieve messages when needed.
AMQ 7 contains its own built-in message store, which consists of an append-only message journal. It does not use an index.
For more information about these changes, see Message Persistence.
Broker Deployment Changes
In AMQ Broker 7, broker deployment differs from AMQ 6 in the following ways:
Deployment mechanism
AMQ 6, by default, was deployed in Apache Karaf containers. AMQ Broker 7 is not.
Deploying multiple brokers
In AMQ 6, to deploy multiple brokers, you either had to deploy a collection of standalone brokers (which required you to install and configure each broker separately), or deploy a fabric of AMQ brokers using JBoss Fuse Fabric.
In AMQ Broker 7, deploying multiple brokers involves installing AMQ Broker 7 once, and then on the same machine, creating as many broker instances as you require. AMQ Broker 7 is not intended to be deployed using fabrics.
1.3.2. Message Address Changes in AMQ 7
AMQ 7 introduces a new addressing and routing model to configure message routing semantics for any messaging protocol (or API in the case of JMS). However, this model does require you to configure address, queue, topic, and routing functionality differently than in AMQ 6. As part of your migration planning, you should be prepared to carefully review the new addressing model and its configuration elements.
AMQ Broker 7 does not distinguish between JMS and non-JMS configuration. AMQ Broker 7 implements addresses, routing mechanisms, and queues. Messages are delivered by routing messages to queues based on addresses and routing mechanisms.
Two new routing mechanisms—multicast and anycast—enable AMQ Broker 7 to route messages in standard messaging patterns. Multicast routing implements a publish-subscribe pattern in which all subscribers to an address receive messages sent to the address. Alternatively, anycast routing implements a point-to-point pattern in which only a single queue is attached to an address, and consumers subscribe to that queue to receive messages in round-robin order.
Related Information
- For more information about the new addressing model in AMQ Broker 7, see Configuring addresses and queues in Configuring AMQ Broker.
- For more information about how message addressing is configured in AMQ Broker 7, see Message Addresses and Queues.
1.4. Reviewing New Features and Known Issues in AMQ 7
Before migrating to AMQ 7, you should understand the key new features, enhancements, and known issues. For a list, see the Release Notes for Red Hat AMQ Broker 7.8.
1.5. Document conventions
This document uses the following conventions for the sudo command and file paths.
The sudo command
In this document, sudo is used for any command that requires root privileges. You should always exercise caution when using sudo, as any changes can affect the entire system.
For more information about using sudo, see The sudo Command.
About the use of file paths in this document
In this document, all file paths are valid for Linux, UNIX, and similar operating systems (for example, /home/...). If you are using Microsoft Windows, you should use the equivalent Microsoft Windows paths (for example, C:\Users\...).
