Chapter 5. Fixed issues

This section describes a highlighted set of issues that have been fixed in AMQ Broker 7.8. For a complete list of issues that have been fixed in the release, see AMQ Broker 7.8.0 Fixed Issues and AMQ 7 Broker - 7.8.x Resolved Issues.

  • ENTMQBR-1815 - Hawtio view changes on automated refresh

    Previously, when automatic refresh was enabled, the Hawtio console updated the screen every 5 seconds. This behavior also switched the view to the Attributes tab, causing you to lose focus from any other tab you were viewing. This issue is now resolved.

  • ENTMQBR-2890 - Infrequently, creating a CR instance with size n > 1 causes the the nth broker pod to start and immediately restart once

    Previously, if you used a Custom Resource (CR) instance to deploy a broker cluster using the AMQ Broker Operator, the final broker Pod in the deployment (as determined by the size property of your CR) started and then immediately restarted one time before it was usable. This issue is now resolved. None of the broker Pods in the deployment undergo a restart before they are usable.

  • ENTMQBR-3059 - AMQ Broker Operator: Operator doesn’t pick up CR name after restart / update

    Previously, if you created a clustered broker deployment of two or more brokers that were configured to use persistence and message migration, the AMQ Broker Operator might generate an invalid name when instantiating the scaledown controller for message migration. Specifically, this issue occurred if the Operator had been restarted or its image had been updated prior to scaledown of the broker deployment. The result of this situation was that you needed to delete and recreate your broker deployment. This issue is now resolved.

  • ENTMQBR-3514 - AMQ Broker Operator: Address not created if address CR is submitted before broker instantiated

    Previously, for an Operator-based broker deployment, if you created a Custom Resource (CR) instance for addresses before the brokers had been instantiated, the Operator failed to create the addresses. This issue is now resolved.

  • ENTMQBR-3578 - AMQ Broker Operator: No operator support for, upon startup, using the existing CR instances as a baseline to move forward from

    Previously, when the AMQ Broker Operator started, it did not check for existing Custom Resource (CR) instances in your project. This behavior meant that if you needed to restart the Operator (for example, to apply a new Operator image version), the Operator and the broker deployment were no longer in sync. In this situation, you needed to delete and then recreate your broker deployment. This issue is now resolved.

  • ENTMQBR-3587 - Avoid notifications when shutting down on critical IO error

    Previously, when shutting itself down due to a critical IO error, the broker generated multiple notifications that triggered disk IO. These notifications could delay or event prevent shutdown of the broker. This issue is now resolved.

  • ENTMQBR-3617 - User information on the hawtio console for durable address is null

    Previously, when a consumer created a shared, durable subscription, the AMQ Management Console might show the associated user as null for the subscription queue that was automatically created by the broker. This issue is now resolved.

  • ENTMQBR-3692 - User information on the hawtio console for durable address is null

    Previously, if a message-driven bean (MDB) used the ActiveMQ Java Connector Architecture (JCA) resource adapter (for example, in Red Hat JBoss Enterprise Application Platform) to create a durable topic subscription, the MDB would fail to deploy. This issue is now resolved.

  • ENTMQBR-3705 - LVQ + non-destructive not delivering message to existing consumer

    Previously, when a consumer created a shared, durable address, AMQ Management Console might show the associated user as null. This issue is now resolved.

  • ENTMQBR-3710 - Incorrect audit message on queue resume

    Previously, if you paused and then resumed a queue, the audit logger incorrectly included text that described the resume event as another pause event. For example:

    2020-07-09 11:18:00,352 [AUDIT](qtp795748540-39) AMQ601213: User amq(amq)@192.168.100.1:40858 is resuming on target resource: QueueImpl[name=helloworld, postOffice=PostOfficeImpl
    2020-07-09 11:18:00,352 [AUDIT](qtp795748540-39) AMQ601721: User amq(amq)@192.168.100.1:40858 has paused queue helloworld

    This issue is now resolved.

  • ENTMQBR-3719 - LegacyLDAPSecuritySettingPlugin allows new user to access any newly created destinations

    Previously, when a new permission was added to LDAP, the LegacyLDAPSecuritySettingPlugin plugin used the new permission to modify the default security match. This could break authorization for existing users. This issue is now resolved.

  • ENTMQBR-3726 - JVM property hawtio.role doesn’t parse a role with space and hyphen

    Previously, if the artemis.profile file defined a hawtio.role property containing whitespace or a hyphen, the property didn’t work properly. This issue is now resolved.

  • ENTMQBR-3744 - Enabling group rebalancing with default / non-zero consumer-window-size can lead to out-of-order message consumption

    Previously, if some connected consumers were using a value of consumerWindowSize greater than zero (meaning that messages were pre-fetched into buffers on those clients) and you configured the broker to use group rebalancing (by setting group-rebalance or default-group-rebalance to true), this might result in out-of-order message consumption. This issue is now resolved.

  • ENTMQBR-3752 - Backup broker cannot reestablish connection with its master

    In the event of a network outage, it is possible for both brokers in a live-backup group to become live at the same time (a situation known as network isolation or split brain). Previously, if this situation occurred, any connected AMQ Core Protocol JMS clients received incorrect broker topology information. As a result, when the network and split brain issues were solved, the client could not reconnect to the right brokers. To work around this issue, you needed to restart the clients. This issue is now resolved.

  • ENTMQBR-3782 - page-max-concurrent-io cannot be disabled

    Previously, setting the value of page-max-concurrent-io to -1 to remove the upper limit on the number of concurrent reads allowed on paging did not work. Instead, the broker continued to use the default value, or the previously configured value, if you had changed it from the default. This issue is now resolved.

  • ENTMQBR-3797 - Activation failure can result in zombie broker

    In prior releases, if a live-backup broker group was configured to use shared store high availability, the live broker might fail to properly activate after a restart, but would continue to hold the journal lock. For example, this issue might occur if the live-backup group was using a network file system (NFS), and the NFS was unexpectedly stopped or removed, causing the live broker to restart. This situation resulted in a non-functional broker that couldn’t service clients but which prevented the backup broker from activating. This issue is now resolved.

  • ENTMQBR-3798 - JDBC XML config can’t use custom password codec

    Previously, if you specified a masked password for the jdbc-password parameter and a custom codec for the password-codec parameter in your broker configuration, the broker always used the default org.apache.activemq.artemis.utils.DefaultSensitiveStringCodec codec to decode the password. This issue is now resolved.

  • ENTMQBR-3812 - Potential deadlock when destroying a queue and depaging concurrently

    Previously, if a queue was destroyed (for example when a non-durable consumer closed its connection) and depaging was concurrently happening, this might result in a deadlock condition. This issue is now resolved.

  • ENTMQBR-3813 - Null pointer exception on queue update

    Previously, if you tried to update a queue that was originally created without a filter, the broker might display a null pointer exception (NPE). This issue is now resolved.

  • ENTMQBR-3841 - Concurrent Jolokia operations can incorrectly update artemis-roles.properties or artemis-users.properties

    Previously, if multiple, concurrent Jolokia operations that manipulated users and roles or permissions took place on the broker, the broker might incorrectly update or remove some data in the artemis-roles.properties or artemis-users.properties configuration files. This issue is now resolved.

  • ENTMQBR-3880 - Destination header replaced for wildcard address during paging

    Previously, before a message was stored, the broker set the address field on the message to reflect the page store name. If the message was first paged for a consumer that subscribed using a wildcard address expression, this resulted in an incorrect destination name header that other consumers could not process. This issue is resolved. The broker no longer changes the message content when writing the message to the page store. This leaves the original target address intact.

  • ENTMQBR-4034 - LVQ broken after restart

    Previously, after a broker restart, an existing message in a last-value queue was not replaced with a new message that was sent to the queue with the same last-value key. This issue is now resolved.

  • ENTMQBR-4143 - AMQ Broker Operator: Type mismatch for pageSizeBytes property between CRD and Operator

    In the previous release, if you added an address settings configuration to the Custom Resource (CR) instance for a broker deployment (that is, by adding an addressSettings.addressSetting section), you could not include the pageSizeBytes property. If you included this property and specified a value, the Operator either failed to process the CR, or it processed the CR but could start any brokers. This issue is now resolved.

  • ENTMQBR-4144 - AMQ Broker Operator: Address setting redeliveryCollisionAvoidanceFactor cannot be specified

    In the previous release, if you added an address settings configuration to the Custom Resource (CR) instance for a broker deployment (that is, by adding an addressSettings.addressSetting section), you could not use the redeliveryCollisionAvoidanceFactor property. If you included this property and specified a value, the Operator failed to process the CR. This issue is now resolved.

  • ENTMQBR-4145 - AMQ Broker Operator: Address setting autoCreateJmsTopics cannot be specified

    In the previous release, if you added an address settings configuration to the Custom Resource (CR) instance for a broker deployment (that is, by adding an addressSettings.addressSetting section), you could not use the autoCreateJmsTopics property. If you included this property and specified a value, the Operator processed the CR but failed to include the property in the resulting broker configuration. This issue is now resolved.

  • ENTMQBR-4146 - Broker fails to start when default-group-rebalance-pause-dispatch property is specified in address settings

    Previously, if you configured the address-setting element of the broker.xml configuration file to set the value of the default-group rebalance-pause-dispatch property to true, the broker could not start.

    This issue also occurred for broker deployments on OpenShift Container Platform. Specifically, if you added an address settings configuration to the Custom Resource (CR) instance for the broker deployment (that is, by adding an addressSettings.addressSetting section) and set the value of the defaultGroupRebalancePauseDispatch property to true, the brokers in the deployment could not start.

    This issue is now resolved.

  • ENTMQBR-4159 - AMQ Broker Operator: Route not created for STOMP protocol

    In prior releases, if you defined an acceptor to use the STOMP protocol, but did not specify a port for the acceptor to use, the Operator failed to create a Service and Route for the acceptor. This issue is now resolved.

  • ENTMQBR-4195 - Deleted scheduled message reappears after AMQ broker restart

    In prior releases, if you used the management API to delete a scheduled message, the message was removed from memory but not from storage. This caused the message to reappear when you restarted the broker. This issue is now resolved.

  • ENTMQBR-4263 - A message becoming large through DLQ shuts down the broker

    Previously, if a message for given protocol was close to the configured large message size for that protocol and the broker attempted to deliver the message to a dead letter queue, the broker might unexpectedly shut down. This issue is now resolved.

Additional resources