What's New With ActiveMQ v5.16.4

Client-Side Max Message Size Detection

In previous versions of ActiveMQ, an exception case that limited the ability for developers to code fully self-healing message flows was when a client sends a message that exceeds the broker's max message size limit. ActiveMQ brokers detect this scenario and immediately close the connection to prevent any negative impact to the broker by misbehaving clients. While this approach is great for protecting the broker, it does not provide any signaling to the client as to how to respond. Before 5.16.4, clients configured with failover would reconnect and retry messages that were too large, causing sent messages to run in an infinite loop.

In 5.16.4, the client library detects the scenario and throws a JMSException with Error Code (41300). Also, there is now a MaxFrameSizeExceeded exception that is accessible as the linked exception off the JMSException. This allows clients to cleanly detect this scenario, take corrective action, and continue to process the next message.

Bonus: since the client is detecting messages that exceed the limit, the data is never sent over the wire to the broker. This saves on bandwidth and broker-side resources.

Double bonus: since the change is with the client library, you can use the activemq-client 5.16.4 jar in your application and point it to the older ActiveMQ 5.15.x brokers and it works!

Clustering Improvements

Before 5.16.4, ActiveMQ clusters all needed to share credentials. Now, clusters can be connected with different credentials. This allows the ability to build wider broker mesh architectures across cloud zones and Kubernetes clusters without having to align the cluster account and password.

Additionally, the feature that supports stamping messages with the identity of the producer's user account will be preserved when messages flow across brokers in the cluster. Previously, the identity would be overwritten with the cluster account identity.

Use cases:

• Integrating cloud zones
• Separating disaster recovery environment credentials
• Store-and-forward web (or IOT) broker gateways to distribution broker clusters
• Wiretapping message flows from one environment to another

Reload4j 

The log4j dependency has been replaced with reload4j. While the actual security concern for ActiveMQ 5.16.x was near-zero (since the issues were related to unused components), this change will help keep security scanners happy by removing false positives.

Constrained Queue Detection Improvements

When a queue is under heavy load (think: 400+ producers and consumers with a low number of messages present in the queue), the broker will detect a scenario where multiple threads are reading the same messages from the disk with a new metric on the queue called "DuplicateFromStoreCount." While duplicate messages are never sent to clients, this scenario indicates an over-taxing of the broker which can lead to lower overall throughput.

ActiveMQ 5.16.4 can now be monitored to signal that more resources need to be added to the broker or the client thread counts should be lowered.

The Usual

Dependency updates, logging improvements (fewer stack traces for client network disconnects, etc.) — these updates and improvements can be seen in more detail in the ActiveMQ 5.16.4 release notes.