Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Result
Message back up in the queues on the broker and are not being drained by the consumer. This may eventually lead to OOM as the VM cannot garbage collect the message refs. This could happen slowly over a period of time, so the MINA buffers may be empty (or at least not represent any significant amount of memory use). Topaz had one example of this with the India client not draining their queue.

2. Unconsumed messages remain in Queues (PubSub)

...

Result
Messages back up in the broker and with durable subscriptions never go away. The broker OOMs are the queues are full. Again this happens over time and the MINA buffers may not be impacted. An example of this is the Topaz MDS data where the subscriptions use selectors. Without TTL set (and set low enough) then the data backs up in the client's sub queues.

...

Result
The message(s) remain in the broker and can cause OOM, particularly when there's a burst of large messages together. An example of this is the Qlib issue where they had a spate of large messages and client side OOM precluded them being processed. It can happen slowly, and with persistent messages costs at least twice as much heap. Broker OOM follows eventually. Topaz also had a variant of this with PubSub large messages.

Plan

To implement this, the following changes are necessary:

...