Chapter 4. Fixed issues

  • ENTMQBR-1942 - [AMQ 7.2, shared store, scale down] NullPointer exception when slave activates and tries to scale down

    Previously, if you configured a slave broker to use a shared store and scaledown in a cluster, you could encounter an exception on the slave if the master broker went offline. This issue is resolved.

  • ENTMQBR-3103 - [AMQ7, AMQP, Openwire] Issue consuming AMQP message using OpenWire consumer

    Previously, when a message was converted from OpenWire to AMQP and then back to OpenWire, the message could no longer be consumed by an OpenWire client. For example, this situation might occur when:

    1) An OpenWire client sent a message to the broker

    2) An AMQP client consumed the message

    3) The AMQP client returned the message to the broker

    4) An OpenWire consumer tried to consume the message

    This issue is now resolved.

  • ENTMQBR-3130 - Broker Operator doesn’t recreate Address after broker redeploy

    Previously, if you used a Custom Resource (CR) instance to create addresses in an Operator-based broker deployment, the Operator did not recreate those addresses if you removed and then redeployed the brokers. This issue is now resoled.

  • ENTMQBR-3137 - Broker Operator does not automatically deploy CR-created addresses on scale-up

    In prior releases, if you used a Custom Resource (CR) instance to create addresses in an Operator-based broker deployment, and then scaled up the size of that deployment, the Operator did not automatically deploy existing addresses to the new broker instances. Instead, you needed to delete the address CR, before redeploying the CR for the scaled-up broker deployment. This issue is now resolved. When you scale up the size of a broker deployment, the Operator automatically deploys existing addresses to the new broker instances.

  • ENTMQBR-3228 - Operator Pod not authenticating correctly when processing address CR

    In prior releases, if you used the AMQ Broker Operator to create a broker Pod that required login (that is, by setting requireLogin to true in the Custom Resource (CR) used for the deployment), any addresses you tried to create on the broker via a CR were not created. This issue is now resolved.

  • ENTMQBR-3328 - "FQQN support is limited to Anycast queues where the queue name equals the address" error occurs

    In prior releases, if a client specified a fully qualified queue name (FQQN) when it used the artemis producer command to send messages to a queue with the anycast routing type, the broker connection returned an error if the queue and its address had different names, for example, fqqn://exampleaddress::examplequeue. This issue is now resolved.

  • ENTMQBR-3356 - AMQP consumption stalls under during high message throughput

    Previously, if a broker in a live-backup group configured to use the replication high-availability (HA) policy experienced a very high throughput of AMQP messages (that is, a rate of 10,000 or more messages per second) message consumption might stall. In addition, the broker and clients might display errors such as "Could not complete operations" (broker) and "Remote did not respond to a drain request in time" (client). This issue is now resolved.

  • ENTMQBR-3365 - Paging is Broken for AMQP

    By default, when you first get a message after the page cache has been evicted, the broker reads the entire page back into the cache. This behavior is specified by the read-whole-page configuration parameter, which has a default value of true. If you set the value of read-whole-page to false, the broker reads messages back into the page cache on a message-by-message basis instead.

    Previously, reading messages back into the cache on a message-by-message basis did not work if you were using the AMQP protocol. If you were using AMQP, you needed to ensure that the value of read-whole-page was set to true. This issue is now resolved.

  • ENTMQBR-3370 - LegacyLDAPSecuritySettingPlugin ignores group changes

    Previously, if you made an update on an LDAP server, the LegacyLDAPSecuritySettingPlugin security settings plugin configured on the broker might not immediately detect the change. For example, if you added a new user to an existing group on the LDAP server, the plugin did not immediately authorize the new user with the same broker permissions as existing users in the same group. Instead, for a change such as this to take effect, you needed to restart the broker. This issue is now resolved.

  • ENTMQBR-3372 - Broker created using Operator fails to start if Base64-encoded keyStorePassword and trustStorePassword values contain "/"

    Previously, a broker instance created using the Operator failed to start if Base64-encoded keyStorePassword and trustStorePassword values that you specified when configuring Transport Layer Security (TLS) on the broker contained a "/" (that is, a forward slash) character. This issue is now resolved.

  • ENTMQBR-3380 - AMQP shared non-durable queues are not being deleted same as Core

    Previously, the broker did not automatically delete a shared, non-durable queue created by an AMQP producer if the queue had at least one message in it, even if the queue had no connected consumers. This issue is resolved. The broker now marks a shared, non-durable AMQP queue as temporary, in the same way that it does for the Core protocol. This means that the broker automatically deletes such a queue when there are no connected consumers.

  • ENTMQBR-3383 - Deletion of address custom resource instance removes address and messages

    Previously, if you deleted the Custom Resource (CR) instance used to create addresses in a broker deployment, this also removed existing addresses and any associated messages for all brokers in the deployment. This issue is resolved. A new configuration item called removeFromBrokerOnDelete in the address CR enables you to specify whether the Operator removes existing addresses in your broker deployment when you delete the underlying address CR. By default, removeFromBrokerOnDelete is set to false, which means that existing addresses are not removed.

  • ENTMQBR-3386 - [AMQ7, message expiry, auto-delete] auto-created queue may not be auto-deleted when messages expire

    Previously, the broker did not delete an automatically-created queue in the case where no consumers ever connected to the queue and all messages on the queue had expired. This issue is resolved. The broker deletes the automatically-created queue in this situation.

  • ENTMQBR-3409 - JMX/Jolokia addSecuritySettings - permissions are not processed until broker restart

    Previously, if you used Jolokia to dynamically set security settings for an address, the broker did not detect the update. Instead, you needed to restart the broker for the changes to take effect. This issue is now resolved.

  • ENTMQBR-3432 - OpenWire consumption stalls under during high message throughput

    Previously, if a broker in a live-backup group configured to use the replication high-availability (HA) policy experienced a very high throughput of OpenWire messages (that is, a rate of 10,000 or more messages per second) message consumption might stall. In addition, the broker and clients might display errors such as "Could not complete operations" (broker) and "Remote did not respond to a drain request in time" (client). This issue is now resolved.

  • ENTMQBR-3490 - The createSession() method throws java.lang.NullPointerException

    Previously, if you used javax.jms.Connection.createSession() to create a session on a connection, you could see a null pointer exception. Specifically, this exception could occur if multiple threads were using the connection, and one thread closed the connection while the createSessionInternal method concurrently tried to create the session on a separate thread. This issue is resolved. Now, there are concurrency protections that prevent this type of exception from occurring.

  • ENTMQBR-3597 - Statefulset recreated on startup

    Previously, if you deployed a Custom Resource (CR) instance to create an Operator-based broker deployment, the Operator created a StatefulSet for the deployment, immediately removed the StatefulSet, and then created it one more time. As a result of this issue, the broker Pods created for the deployment started, immediately terminated, and then started again. This issue is now resolved.