SuoNayi,
I guess what I was trying to elude to was that there is no dispatch
queue per say but just a dispatch count. The queue that the message was
dispatch from is the queue for the message, and the metrics are a
representation of what the broker has done with those messages in the
queue.
Seems like i keep having the issue even after increasing the limit. I
wonder what does the 'WriteChecker message really means. And why can't the
connection remain stable? Is there a way to automatically recycle the
connection to keep it fresh?
Any suggestions appreciated.
On Mon, Dec 24, 2012
Can you attach a JConsole screenshot of the Broker MBean attributes?
Does this happen with just one destination or with all?
The Inactivity Monitor WriteChecker is doing exactly what you pursue:
keeping the connection alive by sending pings back and forth.
It doesn't report errors, so it looks
Thanks. I'll have to look into how to get the JConsole screenshot as I've
never done it before. Do you think there might be something wrong with the
my listener? I suspect the broker is working fine but the listener is the
one that is dying. I'll try to debug with the JConsole. Thanks!
On Tue,
Merry Christmas!
Chirs, you can see the dispatched queue size in the page by viewing
the active consumers of some queue on the web console.
There will be one dispatched list inside every subscriber in the broker.
That list is used to track the messages that are dispatched to consumers
but are not
