Chapter 3. New and Changed Features
This section describes a highlighted set of enhancements and new features in AMQ Broker 7.11.
- Limiting disk space used for paging
- If you configure AMQ Broker to page messages, you can limit the disk space used to page incoming messages to prevent the paging operation from using excessive disk space. For more information, see Limiting disk usage during paging for specific addresses in Configuring AMQ Broker.
- Limiting the memory used for messages read from paging
- If you configure AMQ Broker to page messages, you can limit the memory used to store messages that the broker transfers from disk back to memory when clients are ready to consume messages. For more information, see Controlling the flow of paged messages into memory in Configuring AMQ Broker.
If client applications leave too many messages pending acknowledgment, the broker does not read paged messages until the pending messages are acknowledged, which can cause message starvation on the broker.
For example, if the limit for the transfer of paged messages into memory, which is 20MB by default, is reached, the broker waits for an acknowledgment from a client before it reads any more messages. If, at the same time, clients are waiting to receive sufficient messages before they send an acknowledgment to the broker, which is determined by the batch size used by clients, the broker is starved of messages.
To avoid starvation, either increase the broker limits that control the transfer of paged message into memory or reduce the number of delivering messages. You can reduce the number of delivering messages by ensuring that clients either commit message acknowledgments sooner or use a timeout and commit acknowledgments when no more messages are received from the broker.
You can see the number and size of delivering messages in a queue’s Delivering Count and Delivering Bytes metrics in AMQ Management Console.
- Log4j 2 logging support
- Starting in 7.11, AMQ Broker uses the Log4j 2 logging utility instead of the JBoss Logging framework to provide message logging. You can customize the Log4j 2 logging configuration on both OpenShift Container Platform and RHEL platforms.
- Changing the Operator logging level
- In AMQ Broker 7.11 on OpenShift Container Platform, you can change the default logging level to increase or decrease the detail that is written to the Operator logs. For more information, see Changing the logging level for the Operator in Deploying AMQ Broker on Openshift.
- Support for Java Authentication and Authorization Service (JAAS) login modules
- In AMQ Broker 7.11 on OpenShift Container Platform, you can configure JAAS login modules in a secret instead of using the ActiveMQArtemisSecurity CR to configure user authentication and authorization for AMQ Broker. By configuring JAAS login modules in a secret, you can update user and role information in properties files without needing to restart the broker. In addition, you can configure login modules, such as LDAP, which are not configurable in the CR. For more information, see Configuring JAAS login modules in a secret in Deploying AMQ Broker on Openshift.
- Restricting upgrades
- In AMQ Broker 7.11 on OpenShift Container Platform, the Operator automatically upgrades the broker container images to the latest available version. You can configure the Custom Resource (CR) for your deployment to prevent automatic upgrades or to permit automatic upgrades only to specific versions or to specific broker and init container images.
If you want to restrict automatic upgrades, you must specify either the combined spec.deploymentPlan.image and spec.deploymentPlan.initImage attributes or the spec.version attribute, but not both, in the CR.
For more information, see Restricting automatic upgrades in Deploying AMQ Broker on Openshift.
- Extended status reporting
In AMQ Broker 7.11 on OpenShift Container Platform, the status information reported by the Operator in the main broker CR is extended to include:
- The validity of the content of the CR.
-
The application of properties configured in the
brokerPropertiesattribute. - The propagation of Java Authentication and Authorization Service (JAAS) login module files in a secret to the broker Pods.
- The version of the broker that is deployed and the URLs of the broker and init container images for that version.
- The ability to apply major, minor, patch and security upgrades to the deployment.
- Synchronous mirroring support
- Starting in 7.11, you can configure synchronous mirroring between brokers to ensure that messages are written to the volumes of both brokers in the mirror at the same time. By using synchronous mirroring, you ensure that the mirrored broker is up-to-date for disaster recovery. For more information, see Configuring broker connections in Configuring AMQ Broker.
- Pod disruption budget
- In AMQ Broker 7.11 on OpenShift Container Platform, you can configure a Pod disruption budget to specify the minimum number of Pods in a cluster that must be available simultaneously during a voluntary disruption, such as a maintenance window. For more information, see Configuring a Pod disruption budget in Deploying AMQ Broker on OpenShift.
- brokerProperties configuration is stored in a mutable secret
-
In AMQ Broker 7.11 on OpenShift Container Platform, the configuration created by using the
brokerPropertiesattribute in the CR is stored in a mutable secret. A mutable secret can be updated without requiring a broker restart. Therefore, configuration updates are applied when the broker reloads the configuration periodically, apart from any update that specifically requires a broker restart. - Operations to control the embedded web server
-
Starting in 7.11, you can stop and restart the embedded web server for AMQ Broker by using the
stopEmbeddedWebServer,startEmbeddedWebServerandrestartEmbeddedWebServeroperations on the ActiveMQServerControl JMX MBean. By using these operations, you can avoid restarting AMQ Broker if, for example, you renew the SSL certificate for AMQ Broker. - The credentials used to log in to AMQ Management Console are used to send messages
In previous versions of AMQ Broker, it was necessary to specify a username and password in the AMQ Management Console Preferences page in order to send messages in AMQ Management Console. Starting in 7.11, messages are sent using the credentials that you use to log in to AMQ Management Console.
You can override the default behavior and specify different credentials to send individual messages. For more information, see, Sending messages to an address in Managing AMQ Broker.
- AMQ Broker on OpenShift Container Platform is preconfigured to collect metric data for Prometheus
- In AMQ Broker 7.11 on OpenShift Container Platform, the AMQ Broker container Pods are preconfigured to allow the Prometheus Operator Service Monitor to collect metric data. In previous releases, you needed to expose the port required by Service Monitor to collect metric data.
- Setting environment variables for broker containers
-
In AMQ Broker 7.11 on OpenShift Container Platform, you can set environment variables in a Custom Resource (CR) that are passed to each broker container. For example, you can add the
TZenvironment variable to set the timezone of the broker container. For more information, see Setting environment variables for broker containers in Deploying AMQ Broker on OpenShift. - Proxy forwarding support on OpenShift Container Platform
- In AMQ Broker 7.11 on OpenShift Container Platform, the embedded web server, which hosts AMQ Management Console, is preconfigured to handle X-Forwarded headers. By handling X-Forwarded headers, AMQ Management Console can receive header information that is otherwise altered or lost when a proxy is involved in the path of a request. For example, AMQ Management Console uses HTTP but the OpenShift Container Platform router, which is a proxy, exposes AMQ Management Console using a HTTPS route that terminates at the router. From the X-Forwarded header, AMQ Management Console can identify that the connection between the browser and the router uses HTTPS and switch to HTTPS to serve browser requests.
- Some redelivery attributes are supported only in the
brokerPropertiesCR attribute If a 7.8.x or 7.9.x deployment has the
redeliveryDelayMultiplieror theredeliveryCollisionAvoidanceFactorattributes configured in thespec.deploymentPlan.addressSettings.addressSettingCR element, you must configure these attributes in thebrokerPropertiesCR attribute after you upgrade to 7.11.x. This is required because the data type of both attributes changed from float to string in 7.10.0. As a result, these attributes are no longer supported in thespec.deploymentPlan.addressSettings.addressSettingattribute.The following example shows how to configure both attributes in the
brokerPropertieselement:spec: ... brokerProperties: - "addressSettings.#.redeliveryMultiplier=2.1" - "addressSettings.#.redeliveryCollisionAvoidanceFactor=1.2" ...
NoteIn the
brokerPropertiesattribute, use theredeliveryMultiplierattribute name instead of theredeliveryDelayMultiplierattribute name that was used in thespec.deploymentPlan.addressSettings.addressSettingelement.- Disabling XML External Entity (XXE) processing
-
If you don’t need to modularize your broker configuration in separate files that are included in the
broker.xmlfile, you can now disable XXE processing to protect against XXE security vulnerabilities. Where possible, Red Hat recommends that you disable XXE processing. For more information, see Disabling External XML Entity (XXE) processing in Configuring AMQ Broker. - JGroups 5.x
- Versions of AMQ Broker before 7.10.0 used JGroups 3.x. AMQ Broker 7.11 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.11.
- Contents of AMQ Broker archive extracted to a specific directory name
-
When you extract the AMQ Broker archive on Red Hat Enterprise Linux, the contents of the archive are extracted to a directory called
apache-artemis-2.28.0.redhat-00004in your current directory. - Operator channels
The AMQ Broker Operator,
Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch), is available with the following channels:-
7.11.x- This channel provides updates for version 7.11 only and is a Long Term Support (LTS) channel. -
7.10.x- This channel provides updates for version 7.10 only and is a Long Term Support (LTS) channel.
-
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.
- Change to class name of the Prometheus metrics plugin
-
In AMQ Broker 7.11, the class name of the Prometheus metrics plugin that is included with AMQ Broker changed from
org.apache.activemq.artemis.core.server.metrics.plugins.ArtemisPrometheusMetricsPlugintocom.redhat.amq.broker.core.server.metrics.plugins.ArtemisPrometheusMetricsPlugin. If the Prometheus metrics plugin is enabled in a previous version of AMQ Broker, you must update the class name in thebroker.xmlconfiguration file when you upgrade to AMQ Broker 7.11. For more information, see Upgrading a broker instance from 7.10.x to 7.11.x in Managing AMQ Broker. - Changes to the data returned by the listProducers API method and the listProducersInfoAsJSON JMX method
In AMQ Broker 7.11, the following are enhancements to how data is returned by the
listProducersmethod, which is used by AMQ Management Console:-
In the data returned in previous versions, a producer was displayed per-session. Therefore, if you created a producer using the Core protocol, which creates two sessions per-producer, separate producers are shown for each of the two sessions. Also, if you created a producer without sending messages from the producer, the address returned for the producer was empty. In AMQ Broker 7.11, the
listProducers methodreturns a single producer for the two sessions created by the Core protocol. In addition, the address column shows the correct address, even before you send messages. -
Previously, when you used an anonymous producer to send messages to multiple addresses using the Core or AMQP protocols a producer was displayed for each address. In addition, the address shown was for the first address to which the producer sent the message, which made it appear like a normal producer sending to a single queue. In AMQ Broker 7.11, when you use an anonymous producer to send messages to multiple addresses, a single producer is displayed for each anonymous producer. In addition, the address is not connected to a specific address and has a value of
ANONYMOUS.
Previously, the
listProducersInfoAsJSONmethod provided a count of messages sent to each queue by a particular session. However, this method incorrectly returned a producer for each queue that a message was sent to. For example, if an anonymous producer sent a message to 1000 queues, this method returned 1000 producers. In AMQ Broker 7.11, thelistProducersInfoAsJSONmethod now returns accurately the same data as thelistProducersmethod, but in a different format.In AMQ Broker 7.11, the following new metric data is returned:
Consumers
messagesInTransit- The number of messages for delivery which have not yet been acknowledgedmessagesInTransitSize- The total size of messages for delivery which have not yet been acknowledgedmessagesDelivered- The number of messages deliveredmessagesDeliveredSize- The total size of messages deliveredmessagesAcknowledged- The total number of messages acknowledgedmessagesAcknowledgedAwaitingCommit- The total number of messages in a transaction that are acknowledged but awaiting a commitlastDeliveredTime- The time in milliseconds of the last message deliveredlastAcknowledgedTime- The time in milliseconds of the last message acknowledgedProducers
msgSent- The number of messages sent by a producermsgSizeSent- The total size of messages sent by a producerlastProducedMessageID- The ID of the last message sent-
In the data returned in previous versions, a producer was displayed per-session. Therefore, if you created a producer using the Core protocol, which creates two sessions per-producer, separate producers are shown for each of the two sessions. Also, if you created a producer without sending messages from the producer, the address returned for the producer was empty. In AMQ Broker 7.11, the