Chapter 9. Changes in 3.2.7

Previously, when durable messages were sent to the same queue using both AMQP 1.0 and 0-10 concurrently, a condition could have been triggered where the store no longer flushed the 1.0 messages. When this condition was triggered, the 1.0 messages were only flushed by the 0-10 activity on the queue, or if there was none, then the messages were never flushed.

The code was changed so that any combination of 0-10 and 1.0 messages are successfully processed without causing messages to be delayed.

In certain error situations, it was possible to create a cycle where each end of a connection replied to a "detach" frame with another "detach" frame in an endless loop. When this occurred, the session could not successfully detach and close, so the cluster could not recover.

The code was changed so that it does not send a detach frame when there is an exception on a session that is already detached. This prevents the endless loop and allows the session to detach and close, and subsequently, the cluster can recover.

If a user created a receiver using a queue name that was a prefix of a previously created receiver's name (on the same connection/session), the broker could return access to the wrong one.

The code is fixed so that access to the correct queue is ensured.