Chapter 8. Changes in 3.2.6

Previously, if a queue was set up with a reject-when-full policy, and messages were sent to a full queue via an exchange (for example, by using a topic) and AMQP 1.0 protocol was used, the connection to the client was incorrectly closed.

The code has been updated to handle the error correctly so that the connection is not closed. Now a "queue limit exceeded" error is returned.

If the broker journal-flush-timeout config option was set to something below 1ms, the broker continuously used a noticeable amount of CPU, even at idle.

The flush code has been reworked to minimize CPU usage if there are no messages pending. Now there is almost no CPU usage when the broker is idle, even if the journal-flush-timeout option is set to a very low value.

In MRG 3.2.5, the journal-flush-timeout config setting parsing was incorrectly changed so that the input value was assumed to be milliseconds.

This caused existing config files to not work the same way they did previously.

The parsing has been restored to its previous functionality, so that the setting is interpreted as seconds unless it has a suffix of "ns" (signifying nanoseconds) or "ms" (signifying milliseconds). Now the journal-flush-timeout setting is interpreted the way it was prior to MRG 3.2.5.

A new method ("tick") was added to the Proton C++ connection_driver API.

Customers creating a server process using proton can now use this method to help manage heartbeats from clients.