We encountered an interesting behavior on the Qpid Java broker with respect to memory consumption. Specifically, we reserve certain queues for "suspending" messages. Messages on these suspend queues remain unconsumed and no consumers are setup to listen on them. For the incident in question, we enqueued a handful of messages to the suspend queue. Then, over the course of 2 days, broker heap gradually trended up to 80%. At this point our flow control mechanism kicked in and we stopped enqueuing to the broker.
When we inspected the broker, we found a couple dozen messages on the suspend queue and not much else on the other queues. We then manually triggered GC on the broker but heap utilization remained consistent at 80%. Next, we manually deleted each message from the suspend queue and forced another GC. At this point, heap utilization dropped back to normal levels. This led us to believe that if an unconsumed message M1 is enqueued on queue A, and a message M2 is subsequently enqueued on queue B, then even if M2 is consumed, the memory referenced by M2 will not be reclaimed until M1 is consumed. Unfortunately, we tried to reproduce such a scenario at scale and was unsuccessful. Specifically, GC appears to reclaim memory in the presence of unconsumed messages. We are scratching our heads at the moment and looking for suggestions from Qpid gurus. Is there any condition in which an unconsumed message can prevent GC from reclaiming memory? Our setup is as follows: non-persistent messages, asynchronous onMessage delivery, transaction sessions. Thanks in advance! Dan -- View this message in context: http://qpid.2158936.n2.nabble.com/Possible-for-unconsumed-messages-to-prevent-GC-from-reclaiming-memory-held-by-prior-messages-tp7615368.html Sent from the Apache Qpid users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
