Release Notes for AMQ Online 1.4 on OpenShift

Red Hat AMQ 7.6

Release Notes for AMQ Online 1.4 on OpenShift Container Platform


These release notes contain the latest information about new features, enhancements, fixes, and issues contained in the AMQ Online 1.4 on OpenShift Container Platform release.

Chapter 1. Features

1.1. New Red Hat AMQ Console

Red Hat AMQ Console features a new user interface design. In addition, using the Red Hat AMQ Console you can now change the authentication service that is associated with an address space. For a better user experience when viewing a large number of addresses, you can also sort addresses by message count.

Chapter 2. Enhancements

2.1. Later versions of AMQ Broker and AMQ Interconnect

AMQ Online 1.4 on OpenShift Container Platform is based on AMQ Broker 7.6 and AMQ Interconnect 1.7.

2.2. Ability to expose the maximum and available pods for routers and brokers

You can now configure pod disruption budgets for routers and brokers, so you can expose the maximum and available pods during upgrades, for example. This enhancement allows you to maintain a minimum level of availability during disruptions such as maintenance or while other cluster-wide changes are taking place.

2.3. Consistent use of Custom Resource Definitions (CRDs) for configuring the system

As an improvement to the internal implementation of AMQ Online, certain underlying Custom Resources have been migrated from the use of an aggregate API server to the use of Custom Resource Definitions (CRDs). This change does not affect the definition or use of the Custom Resources for address spaces, addresses, and messaging users. However, the following changes occur at a technical level that you might observe by viewing AMQ Online processes.

Since the address space, address, and messaging user resources are now backed by CRDs, the api-server component is no longer necessary and has been removed. Note that the enmasse-operator component automatically removes the api-server component when upgrading.

The api-server provided a default status section if the object had not yet been processed. With the removal of the api-server component, the Operators maintain the Custom Resource status. It is not until an Operator processes the resource for the first time that the status section is added. Therefore, there is a period of time where a user can observe a new object without a status section.

Resources now make better use of the status section of AMQ Online objects to identify errors and aid in troubleshooting. Certain resource validation that previously occurred in the api-server component has been replaced with a resource status check and a corresponding user error message. For example, on AMQ Online 1.4, after deleting an address plan, if that plan is still referenced by an address, you receive an error message of “Plan not found”.

The address space schema resource has been changed to a cluster-wide CRD. Because the cluster role now grants access to these permissions, if you are using the address space schema resource, when upgrading you need to ensure that the user is given sufficient permissions to be able to read or list this resource. For more information, see the install/components/example-roles/020-ClusterRole-schema.yaml file.

2.4. Added support for specifying maxConsumers for a subscription address

To support shared durable subscriptions, you can now specify maxConsumers for a subscription address in a standard address space. This added support enhances availability and fault tolerance, for example. For more information see Subscription address type.

2.5. Default behavior of handling the REJECT outcome in broker has been changed from putting on a DLQ to retrying indefinitely

When using message store-and-forward, messages are forwarded from a local address to the remote AMQP server outside of AMQ Online, and the messages are then removed from the local address. If the remote AMQP server rejects a message, AMQ Online now retries the delivery of the rejected message until it succeeds. Examples of when the remote server might reject a message include space constraints or other transient issues. If the remote AMQP server is an AMQ broker, be aware that it functions in this way.

2.6. TLS version 1.2 or later is required for TLS connections

As a security enhancement, TLS version 1.2 or later is now required for messaging clients to connect to TLS endpoints.

2.7. Monitoring capability is automatically installed

When installing AMQ Online, the ability to monitor AMQ Online is now also installed, resulting in fewer steps needed to enable monitoring.

Chapter 3. Technology Preview

3.1. Internet of Things (IoT) connectivity

The Internet of Things (IoT) connectivity in AMQ Online provides remote service interfaces for connecting large numbers of IoT devices to a messaging back end. This Technology Preview feature includes the ability to use protocols common to IoT and to enable common IoT use cases, allowing you to register devices and credentials. For more information, see Getting Started with Internet of Things (IoT) on AMQ Online.

For AMQ Online 1.4, metric support for IoT components has been enabled. For more information, see IoT-specific metrics.

Also, the documentation has been improved and expanded, including IoT services configuration examples and new documentation for enabling command and control in Sigfox.

Chapter 4. Resolved issues

4.1. Inconsistency between OpenAPI and code in messaging user model

When using the OpenShift console to create a messaging user with an authorization operation of receive, a warning message was displayed indicating that the value was incorrect. The API documentation has been changed to reflect recv as the correct value instead.

4.2. Resolved issues for AMQ Online 1.4.1

For additional details about all of the issues resolved in AMQ Online 1.4.1, see AMQ Online 1.4.x Resolved Issues.

4.3. Resolved issues for AMQ Online 1.4.2

For additional details about all of the issues resolved in AMQ Online 1.4.2, see AMQ Online 1.4.x Resolved Issues.

4.4. Resolved issues for AMQ Online 1.4.3

For additional details about all of the issues resolved in AMQ Online 1.4.3, see AMQ Online 1.4.x Resolved Issues.

4.5. Resolved issues for AMQ Online 1.4.4

For additional details about all of the issues resolved in AMQ Online 1.4.4, see AMQ Online 1.4.x Resolved Issues.

Chapter 5. Known issues

  • ENTMQMAAS-1281: Resources not deleted when uninstalling AMQ Online using OLM on OpenShift Container Platform 4.1

    Workaround: For the workaround about how to remove all resources when uninstalling AMQ Online using the Operator Lifecycle Manager (OLM), see Removing remaining resources after uninstalling AMQ Online using the Operator Lifecycle Manager.

  • ENTMQMAAS-1799: Possible to define duplicate addresses using router pattern-matching syntax

    When defining addresses in a standard address space instance, be aware that the following restrictions affect the composition of the spec.address field in the address resource.

    The router specifies both period (.) and forward slash (/) characters as address separator characters and that both characters are equivalent. In addition, the router infers a leading address separator character even if it is not explicitly included.

    Since AMQ Online does not encode these rules, care must be taken to avoid defining addresses that collide on the router network.

    Workaround: One way to avoid this collision is to follow these guidelines for defining addresses:

    • Use either a period or a forward slash in the addresses, but do not use both.
    • Do not begin addresses with an address separator character.

    For more information about address pattern matching on the router, see the Red Hat AMQ Interconnect documentation, Address pattern matching.

  • ENTMQMAAS-1952: This issue is related to ENTMQBR-2313. When restarted, the broker can use more memory to read messages from the journal than to process the same messages at runtime. This issue can cause the broker pod to fail with an OutOfMemoryError message. You can view the broker logs to check the reason for the broker pod failure. For more information, see Viewing broker logs.

    The amount of additional memory required during startup varies depending on the contents of the message, including headers, properties, and payload.

    Workaround: The workaround for this issue requires a three-stage procedure. Note that this procedure temporarily increases the memory resources required within your cluster.

    • First, temporarily increase the memory available to brokers.
    • Next, remove the messages that reside on AMQ Online.
    • Finally, set the broker memory size and globalMaxSize to suit your use-case.


    1. Pause your messaging applications so they no longer send messages to AMQ Online.
    2. Log in as a service admin:

      oc login -u admin
    3. Switch to the project where AMQ Online is installed:

      oc project amq-online-infra
    4. Obtain the name of the address space plan:

      oc get addressspace -n namespace address-space-name -o "jsonpath={.spec.plan}"
    5. Obtain the infraconfig resource type, infraconfig name, and the current broker memory settings:

      oc get addressspaceplan address-space-plan -o "jsonpath=infraConfigResourceType={.spec.addressSpaceType}infraconfig infraConfigName{.spec.infraConfigRef} currentBrokerMemory={}"
    6. Obtain a copy of the infraconfig resource settings.

      oc get infraconfig-resource-type infraconfig-name --export -o yaml > infraconfig-name.bak
    7. Increase the broker memory allocation by 1Gi. If the current broker memory is absent from the infraconfig resource settings, start at 2Gi.

      oc patch infraconfig-resource-type infraconfig-name --type=merge -p '{"spec":{"broker":{"resources" : {"memory":"2Gi"}}}}'
    8. The broker pods will restart. If the broker pods restart successfully without the OutOfMemoryError recurring, continue to the next step. Otherwise, repeat the last step.
    9. Remove the messages that reside on AMQ Online by letting the application consume the messages. Alternatively, you can use the purge option available from the Red Hat AMQ Console to remove messages, but these messages will be lost.
    10. Use the Red Hat AMQ Console to verify that all queues and topic subscriptions are at 0.
    11. Use the AMQ Online configuration sizing guidelines to calculate the size of the broker container memory requirements.
    12. Set the broker memory size and globalMaxSize. Use a broker memory size of eight times the globalMaxSize derived from the calculation. This configuration example sets the globalMaxSize to 256Mb:

      oc patch infraconfig-resource-type infraconfig-name --type=merge -p '{"spec":{"broker":{"globalMaxSize": "256Mb", "resources" : {"memory":"2Gi"}}}}'
    13. The brokers will restart. Resume your messaging applications to restart normal operations.

Legal Notice

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.