DefaultMessageListenerContainer and ConcurrentConsumers

[Ben Hale]

Can anyone give me a quick rundown on what concurrentConsumers means in the context of the DefaultMessageListenerContainer. I started using it thinking that it would allow parallel execution of multiple messages, but it appears that it may just process the same indication multiple times. Is that the anticpated behavior, and if so, why would something like that be useful?

[Juergen Hoeller]

DefaultMessageListenerContainer essentially fires up a number of concurrent threads, each having one JMS consumer listening to the given destination. This should result in parallel processing of messages, without receiving the same message multiple times (unless you didn't acknowledge in CLIENT_ACKNOWLEDGE mode, or caused a transaction rollback).

Are you experiencing any unexpected side effects when you increase the number of concurrent consumers?

Juergen

[Ben Hale]

I'm pretty sure that we're seeing multiple receives of the same message. However, I'm not yet sure about the CLIENT_ACKNOWLEDGE mode. I'll need to check the code again. Is that the default if I don't set anything explicitly?

[Juergen Hoeller]

The default is AUTO_ACKNOWLEDGE, or transactional reception (if a transaction manager has been specified).

If you're actually seeing multiple receives of the same message, double-check the configuration of your JMS provider, since it then obviously dispatches the same message to multiple concurrent JMS Sessions.

I assume we're talking about a queue here? Of course, for a topic, the JMS provider would naturally propagate a message to all registered subscribers with matching selector (that is, to each of the concurrent consumers)...

Juergen

[Ben Hale]

Of course it was the simplest thing possible. We just had a mashup of topics and queues and not everybody was assigned to what they actually needed. Some needed the throughput of multiple concurrent listeners while others needed multiple listeners for the same information. In the end we found a good solution making things listen on topics and queues as needed but made sure that the publishing destination (in the JmsTemplate) used an ActiveMQ composite destination.

Thanks again for your help in this situation. I knew the problem was us and not in the Spring code; you almost never find bugs there after all.