Chapter 3. Resolved Issues
ENTMQBR-742 - JMS Queues are not being auto-deleted for Openwire and AMQP clients
Previously, addresses and queues with
<auto-delete-addresses>and<auto-delete-queues>set totruewere not deleted when AMQ OpenWire JMS clients disconnected from them.
ENTMQBR-914 - [AMQ7, broker startup ] AMQ224000: Failure in initialization:
java.lang.IllegalStateException: Cannot find queue with id XXXXIn previous versions of AMQ Broker, the broker would fail to start if you had an XA transaction in the prepared state, then deleted the queue that this transaction used, and then attempted to restart the broker.
ENTMQBR-929 -
LDAPLoginModulecannot process referralsPreviously, the LDAP JAAS login module was unable to handle LDAP referrals, which caused authentication and authorization failures.
ENTMQBR-930 - Unable to login with multiple LDAP modules configured
The commit operation of the LDAP JAAS login module would always return
null, resulting in unexpected behavior when multiple instances of the module were configured in the same domain.
ENTMQBR-943 - [AMQ7, Openwire, Compression] consuming Openwire compressed
bytemessagethrowsjava.util.zip.DataFormatException: incorrect header checkPreviously, when using the OpenWire protocol to send small, compressed ByteMessages that have JMS properties set for a queue, an exception was thrown on the consumer side when it attempted to decompress the message. See the Knowledge Base article on the Red Hat Customer Portal for more details: https://access.redhat.com/solutions/3269061.
ENTMQBR-966 - Unsettled AMQP messages are lost when Receiver Link is opened on remote cluster member
An issue causing message loss has been fixed in this release. Previously, if messages were sent to a broker using the AMQP address, and the address was not set on the messages, then some of the messages could be lost if they were redistributed.
ENTMQBR-967 - [AMQ 7.1.0 CR1.1] Limit non-ssl connection, handshake-timeout not configurable
Previously, the broker did not disconnect unauthenticated clients. With AMQ Broker 7.2, you can use the configuration parameter
handshake-timeoutto limit the amount of time that an unauthenticated client can remain connected.
ENTMQBR-973 - Incorrect message priority displayed in hawtio console
When viewing messages in AMQ Console, the message priority is now correct. Before, the message priority incorrectly defaulted to
4.
ENTMQBR-1016 - [AMQ7,Hawtio]AMQ 7 hawtio console store users password in browser’s local cache after user get logout
A security issue has been fixed for AMQ Console. Before, if you logged into AMQ Console, the value of the
Passwordfield was visible from local storage in Google Chrome Developer tools.
ENTMQBR-1018 - When live-slave fails-back to master, it turns off everything down, even its console
In high-availability configurations, AMQ Console is now accessible when a slave broker returns control to the master broker. Previously, AMQ Console would become unavailable for the slave broker when it gave control back to the master broker.
ENTMQBR-1030 - Restrict directory listings of Hawtio within the web server configuration
AMQ Console no longer permits access to restricted directory listings.
ENTMQBR-1130 - Destinations undeployed when master recovers from outage
When adding destinations to a broker’s configuration file (
broker.xml) at runtime, the destinations are now preserved in the configuration file and reloaded if the broker is restarted. Previously, if you added destinations to a broker’s configuration file, the destinations would not be reloaded when the broker was restarted.
ENTMQBR-1184 - LargeMessage Produced by AMQP Protocol Can Not Be Consumed By AMQP Protocol
In previous releases, if the size of an AMQP JMS Object Message was greater than the value specified for the maximum journal record size, an exception was thrown on the broker and the consumer was not able to receive the message. This issue was caused by a problem in the AMQP large message to core message conversion process.
This issue is fixed and AMQP large messages can be sent and received as usual.
ENTMQBR-1461 - AMQP:
IndexOutOfBoundsExceptionwhen dispatchingObjectMessagethat was handled as a Large MessagePreviously, if you were using the AMQP protocol with the Qpid JMS client, and you sent a JMS
ObjectMessagethat was also a large message (larger than themin-large-message-size), an error would occur when the message was consumed. This error no longer occurs.
ENTMQBR-1466 - [3 HA pairs] Slave does not become live after master is killed and isolates itself
The quorum voting protocol has been corrected. Previously, in high-availability configurations consisting of three high-availability pairs with replication, this issue occasionally prevented slave brokers from taking over during a failover event. Instead, the slave broker would become isolated from the broker cluster.
ENTMQBR-1500 - Jolokia read request does not fetch all attributes
Using Jolokia, it is now possible to request all of the attributes for the broker MBean.
ENTMQBR-1548 - Implementation of AMQP interceptor is passing a null RemotingConnection reference
Previously, if you were using the interceptor API with the AMQP protocol, and you implemented the following method, the connection parameter was always null:
public boolean intercept(AMQPMessage message, RemotingConnection connection)
Now, the connection parameter is properly set.
ENTMQBR-1757 - AMQ Broker throws ERROR if we update the address ANYCAST to MULTICAST or vice-versa in broker.xml
Previously, if the broker was stopped and the routing type for an existing address with queues was changed in the
broker.xmlfile, the broker would fail to restart. The relevant code for updating the configuration has been modified so that such a configuration change is possible, and even if there is an error deploying the address or queue, the broker will log the error and still start.
For additional details about issues resolved in maintenance releases, see the following article:

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.