ENTMQIC-2144 - Fix handling of unsettled multicast

AMQ Interconnect has been enhanced to properly reflect the status of unsettled multicast deliveries. Previously, AMQ Interconnect treated all multicast deliveries as pre-settled ("fire and forget"), which meant that producers always received an accepted response even if the message was not delivered to a consumer.

Now, if a producer sends an unsettled message to a multicast address, AMQ Interconnect sets the inbound delivery’s terminal state based on the dispositions received from the consumers. As a result, the producer receives an indication that at least one consumer accepted, modified, or rejected the message.

For more information about reliability guarantees for unsettled multicast messages, see Message Settlement and Reliability in Using AMQ Interconnect.

ENTMQIC-2269 - Router state dump with qdstat

The qdstat tool has been enhanced with the new --all-routers and --all-entities options. You can use these options to create a state dump of the router network containing all statistics for all routers, a single statistic for all routers, or all statistics for a single router.

Before, you could only display a single statistic for a single router at a time.

For more information, see Creating a State Dump of the Router Network in Using AMQ Interconnect.

ENTMQIC-61 - Memory pools are never returned to heap

Several heavily used data objects (deliveries, messages, links, buffers, etc.) are managed by AMQ Interconnect in pools for efficient allocation. In AMQ Interconnect 1.1, objects in these pools are not returned to the heap at any time. This means that the memory used in large bursts of activity will not be freed, but will remain available for use thereafter.

This might be observed as an increase in memory usage that does not decrease after a burst of activity is completed. Subsequent bursts of activity will use the same memory that was used previously.

Methods of returning large amounts of pooled objects back to the heap are being developed.

ENTMQIC-1980 - Symbolic ports in HTTP listeners do not work

When configuring a listener in the router with the http option enabled (for console or WebSocket access), the port attribute must be expressed numerically. Symbolic port names do not work with HTTP listeners.

If a listener is configured as:

listener {
    ...
    port: amqp
    http: yes
    ...
}

It should be changed to:

listener {
    ...
    port: 5672
    http: yes
    ...
}