Announcement Announcement Module
No announcement yet.
DefaultMessageListenerContainer/ActiveMQ processes in batches Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • DefaultMessageListenerContainer/ActiveMQ processes in batches


    I am noticing some strange behavior from our activeMQ consumer. The producer is sending messages to activeMQ throughout the day, and the messages seem to arrive at the broker. However, the consumer is not notified of these messages.

    2-3 times a day, the consumer is notified and starts processing all the previous messages which have built up in the broker. However, the timing of these batches of processing does not seem to occur at fixed times during the day. The interval between them vary from 2 hours to 20 hours. Also, the batches do not contain the same number of messages each time, but around 500-700 in general.

    The queue size is showing -1800, but I don't know if that would actually cause this issue. I've seen some other reports of a bug mentioning negative queue numbers, but I guess that's just caused by heavy load and duplicate acknowledgements. It shouldn't really affect future processing, would it?

    We are using activeMQ 5.1, and are using a spring DefaultMessageListenerContainer. The producer is using JMSTemplate.

    The DefaultMessageListenerContainer is using the activeMQ connection pool. And yes, I now know I shouldn't use the connection pool on the consumer side but I don't see how that would have caused this issue.

    I am wondering if the prefetch mechanism is causing this, as it would cause the consumer to stop until it has received acknowledgements for all sent messages, but I don't know why it would take 20 hours to send these acknowledgements.

    For activeMQ config we are pretty much using the default, except with no DLQ.


  • #2
    I have noticed similar behaviour with ActiveMQ. Have you tried to see if the 5.3-SNAPSHOT build exhibits the same behavior you're seeing here?

    My suggestion is to use JMeter to blast messages into your consumer thru the queue of course and see if you can reproduce the problem with 5.1 then try the same in 5.3-SNAPSHOT.