activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Green <james.mk.gr...@gmail.com>
Subject Re: DLQ, cause:null
Date Wed, 29 Apr 2015 08:37:49 GMT
On 28 April 2015 at 14:09, Tim Bain <tbain@alumni.duke.edu> wrote:

> On Apr 28, 2015 3:21 AM, "James Green" <james.mk.green@gmail.com> 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 Hawt.io 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
change.

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,
either.

James

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