-percentage-of-dead-letter-queue-messages-tp4689344p4689573.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
messages ending up in a DLQ - sounds like message
> TTLs are expiring because the broker is far too slow delivering the
> messages.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/high-GC-activity-yields-a-high-percentage-of-dead-letter-q
he results described - messages ending up in a DLQ - sounds like message
TTLs are expiring because the broker is far too slow delivering the
messages.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/high-GC-activity-yields-a-high-percentage-of-dead-letter-queu
Agreed. We’re still bringing up some instrumentation using
Grafana/KairosDB so my plan is to get some GC logs and analyze this over
time and look at memory as it grows.
If I can’t get that working in the next few months I might just use data
dog as I know they have a decent JVM memory interface.
That sounds like a plausible explanation of why you DLQ filled in that
situation. The more interesting question is what caused the GCing behavior.
I assume you don't have any GC logs/memory dumps to do forensics against,
so you're stuck trying to reproduce the problem so you can have something
to
I think I figured out a realistic theory as to why my broker died last week
and ended up with my entire queue moving to the dead letter queue.
The problem happens when ActiveMQ goes into a full-GC loop where it
continually spends 100% CPU doing full -GCs.
messages are still served, but only say 1
