Chapter 3. New and Changed Features

This section describes a highlighted set of enhancements and new features in AMQ Broker 7.10.

High availability replication improvements
In previous versions of AMQ Broker, to use a replication high availability (HA) policy, you required at least three live-backup broker pairs. The three pairs were required so either broker in a pair could obtain a majority quorum vote and avoid a scenario where both brokers became live at the same time. Starting in 7.10, you can configure brokers to use the Apache Zookeeper coordination service to coordinate each live-backup broker pair, which eliminates the need to have at least three live-backup pairs. For more information, see Configuring a broker cluster for replication high availability using the ZooKeeper coordination service in Configuring AMQ Broker.
Client connection partitioning

In previous releases, there was no method to partition client connections on the server-side. Starting in 7.10, you can partition client connections, which involves routing connections for individual clients to the same broker each time the client initiates a connection. Two use cases for partitioning client connections are:

  • Partitioning clients of durable subscriptions to ensure that a subscriber always connects to the broker where the durable subscriber queue is located.

  • Minimizing the need to move data between brokers by attracting clients to data where it originates, also known as data gravity.

    To learn more about partitioning client connections, see Partitioning client connections in Configuring AMQ Broker.

AMQ Management Console authentication
To authenticate users with the AMQ Management Console, you can configure certificate-based authentication. To learn how to configure certificate-based authentication, see Configuring the broker console to use certificate-based authentication in Configuring AMQ Broker.
Controlling pod placement on nodes
In an operator-based broker deployment, you can configure a Custom Resource (CR) to control the placement of AMQ Broker pods on OpenShift Container Platform nodes by using node selectors, node affinity rules and taints and tolerations. For more information, see Controlling placement of broker pods on OpenShift Container Platform nodes in Deploying AMQ Broker on OpenShift.
Broker health checks
In an operator-based broker deployment, you can configure periodic health checks on a running broker container by using liveness and readiness probes. A liveness probe checks if the broker is running by pinging the broker’s HTTP port. A readiness probe checks if the broker can accept network traffic by opening a connection to each of the acceptor ports configured for the broker. To learn how to configure health checks, see Configuring broker health checks in Deploying AMQ Broker on OpenShift.
Overriding the default memory limit
In an operator-based broker deployment, you can override the default memory limit that is set for a broker. By default, a broker is assigned half of the maximum memory that is available to the broker’s Java Virtual Machine. To learn how to override the default memory limit, see Overriding the default memory limit for a broker in Deploying AMQ Broker on OpenShift.
Requesting a storage class in a Persistent Volume Claim (PVC)
By default, any Persistent Volume Claim (PVC) by AMQ Broker on OpenShift Container Platform uses the default storage class that is configured for the cluster. With this release, you can configure a CR to specify a storage class for AMQ Broker. To learn how to specify a storage class in a PVC, see Configuring broker storage size and storage class in Deploying AMQ Broker on OpenShift.
Configuring a security context for a pod
In an operator-based broker deployment, you can configure a security context for a pod. A security context defines privilege and access control settings for a pod and includes attributes for discretionary access control, Security Enhanced Linux (SELinux), Secure Computing Mode (seccomp), sysctl interface, and Window’s specific attributes for container running on Windows. For more information, see Custom Resource configuration reference in Deploying AMQ Broker on OpenShift.
Support for OpenShift Container Platform 4.14
In addition to supporting OpenShift Container Platform 4.6, 4.7, 4.8, 4.9 and 4.10, AMQ Broker now supports OpenShift Container Platform 4.14.
Change the default service account name for a broker pod
You can change the default service account name for a broker pod by using the serviceAccountName name attribute. For more information, see Custom Resource configuration reference in Deploying AMQ Broker on OpenShift.
Labeling broker pods
You can assign labels to broker pods by using the labels attribute. For more information, see Custom Resource configuration reference in Deploying AMQ Broker on OpenShift.
Update the acceptor and connector configuration with *StoreType and *StoreProvider
In the CR configuration for acceptors and connectors, you can specify details of the keystore and truststore that the broker uses.
Operator channels

The AMQ Broker Operator, Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch), is available with the following channels:

  • 7.10.x - This channel provides updates for version 7.10 only and is the current Long Term Support (LTS) channel.
  • 7.x - Currently, this channel provides updates for version 7.9 only.
  • 7.8.x - This channel provides updates for version 7.8 only and was the previous Long Term Support (LTS) channel.
Note

It is not possible to upgrade the Operator by switching channels. You must uninstall the existing Operator and install the new version of the Operator from the appropriate channel.

To determine which Operator to choose, see the Red Hat Enterprise Linux Container Compatibility Matrix.

Use a wildcard value to grant access to all domains using the Management API
Starting in 7.10.1, in the management.xml file, you can specify a wildcard value in the entry domain field. When you access the management API, a wildcard value in the entry domain field grants access to all domains. 
 <authorisation>
    <allowlist>
       <entry domain="*"/>
    </allowlist>
JGroups 5.x
Previous versions of AMQ Broker used JGroups 3.x. AMQ Broker 7.10 uses JGroups 5.x which is not backwardly compatible with JGroups 3.x. Some protocols and protocol properties changed between the two JGroup versions, so you may have to change the JGroups stack configuration when you upgrade to AMQ Broker 7.10.