Hi Dan, In general there's nothing I can think of with the current broker that I know of that would explain what you saw, but do I remember correctly that you guys still using 0.16... ? (Not that I recall of any defect in 0.16 that would cause this behaviour).
Without looking at a heap dump from the scenario you found, it's pretty difficult to work out what the cause might be. Certainly, regarding > > 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. > > Yes - there's nothing in the broker that should link messages from unrelated queues. So if there is any linkage in 0.16 it's not as simple as that. Unfortunately all I can suggest to you is that you try to reproduce the issue, take a heap dump at that point and see what is taking up memory and what is referencing those objects causing the issue. Apologies I can't be of more help, Rob On 17 October 2014 01:59, xiaodan.wang <[email protected]> wrote: > 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. 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] > >
