Also note the "can dispatch" logic checks for a match on the consumer group
(yes, the message in the consumer group iterates over all of the consumers
rather than bypassing the loop).
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Dispatch-policy-for-ActiveMQ-with-new-me
It appears that the selection is round-robin, but not in the way you want.
The round-robin of dispatching to clients is performed as usual by ActiveMQ
- meaning every message goes to the next consumer in-line; here's the basic
flow:
ON MESSAGE DISPATCH
LOOP UNTIL no more consumers OR matchi
Ah, I see why the activemq.xml changes now. Two ways to get out of the
activemq.xml:
* Just have the producers directly produce to the two versioned queues, or
* Use a camel route running outside of AMQ to move the messages (one nice
advantage over the existing solution is it takes the overhead o
I recommend first identifying any cause of slow consumption (especially DLQ -
they are notorious) and taking action to eliminate the slow consumption.
For example, a camel route that consumes from the DLQ and logs the messages
is a good way to keep the DLQ from acting as a message store - as long
Hi,
I had the same issue with 2 ActiveMq 5.10 nodes and 3 ZooKeeper nodes.
At first everything worked well but after long running stress tests we had
the same situation were the master would step down and no node would become
the new master. This would break our application and we were glad not
