activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Green <>
Subject Re: DLQ, cause:null
Date Wed, 29 Apr 2015 08:37:49 GMT
On 28 April 2015 at 14:09, Tim Bain <> wrote:

> On Apr 28, 2015 3:21 AM, "James Green" <> wrote:
> >
> >
> > So to re-work my understanding, the pre-fetch buffer in the connected
> > client is filled with messages and the broker's queue counters react as
> if
> > this was not the case (else we'd see 1,000 drop from the pending queue
> > extremely quickly, and slowly get dequeued which we do not see).
> Pretty much right, though I wouldn't say the broker's counters react as if
> this was not the case; rather, the broker's dispatch counter increases
> immediately but the dequeue counter won't increase until the broker removes
> the message, and that won't happen until the consumer acks it.  Until that
> happens, the message exists in both places and the counters reflect that.
> It sounds like you're observing the broker through the web console; there's
> WAY more information available through the JMX beans and you'll understand
> this better by watching them instead of the web console.  So I highly
> recommend firing up JConsole and looking at the JMX beans.

We're going through a firewall which pretty much rules JMX out - plenty of
bad experiences of that scenario.

We tried with but it does not work properly against a remote
broker. The queues appear but they cannot be browsed and the health tab is
empty. Others report the same.

I agree, I don't understand that, particularly because even if the broker
> was so loaded down that you were hitting that timeout, I don't see how that
> would result in a failed delivery attempt.   Your receive() call would just
> return null and Camel would just call receive() again and everything would
> be fine.  (This is exactly what happens when there aren't any messages on
> the queue, and nothing bad happens then.)  So my gut reaction is that the
> timeout is a red herring and something else is going on.  Have you switched
> that setting between the two values while playing identical messages
> (either generated or recorded) to be sure that that setting really is the
> cause of this behavior?

We've not, mainly because we've not spent the time on recording the
individual messages for individual playback.

> Also, when messages are failing, do all of them fail?  If it's only some of
> them, what's the common thread?
We get bursts into the DLQ, which we've put down to possible machine
loading issues at the time. Still nothing recorded since the time-out

Those that were in the DLQ were consumed fine when we reconfigured the app
to read from there so it's not individual messages that will always fail,


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message