Chapter 13. Changes in 3.2.11

Due to a coding error related to journal file management, the Qpid broker can sometimes crash at random times when durable queues are present.

The coding error was fixed and the random crashes should no longer occur.

A Qpid broker containing durable queues, and having a low value set for the 'journal-flush-timeout' parameter can experience a deadlock, causing the broker to hang. A timing flaw was identified with the underlying state machine that processes the asynchronous events related to the data store.

With the fix, Qpid no longer hangs due to this deadlock condition, and durable messages are processed normally.

When a priority ring queue is filled to overflowing with messages of various priorities, and has no consumer, but only a browsing client, an internal data structure accumulates as the messages are delivered to the client, causing a slow memory leak.

The internal data is now released when the message is delivered to the browsing client and the memory leak is no longer present.

On idle timeout, the reactor queued a write of the close frame but waited for the OS to indicate that it had buffer space for the write before actually writing the frame and shutting down the socket. This usually happened immediately. But if the kernel output buffer was full at the time of the timeout, and the network was losing packet transfers with the peer such that it couldn't shrink the output buffer, the cleanup of the socket took arbitrarily long.

Now, a best-effort attempt is made to write the close frame when the idle timeout is detected and to close the socket immediately.

If a Qpid client attempts to connect to an unreachable broker IP address repeatedly, each iteration causes a small memory leak. This can accumulate over time and cause system memory issues.

Now, after a failed connection, the temporary data is freed correctly and repeated attempts to connect no longer cause memory to accumulate.