DefaultMessageListenerContainer not really concurrent

[lkesteloot]

I've got a DMLC with concurrentConsumers set to a non-1 value and ActiveMQ 5.1, no app server, no transactions. I noticed that if one thread gets a message, the next message may go to that same thread, even if that thread is still working in onMessage(). In other words, ActiveMQ doesn't seem to send the message to the consumers that are in receive(), it just sends it to any of the consumers, perhaps one that's blocked for a long time.

Has anyone seen this? Is it an ActiveMQ-specific problem? I was forced to spawn a thread in onMessage() to avoid blocking any consumers, and in fact then dropped my concurrentConsumers to 1, which solved it. This means I can't use transactions or client-ack, though, and it seems weird to have this DMLC with fancy but useless multi-consumer logic.

Lawrence

[chudak]

Spawning a thread in your on message handler is a very bad idea.

I'm not familiar with activemq but what you are describing sounds like a prefetch setting. Prefetch causes the message provider to queue several messages for the consumer which means that they won't be available for another consumer (e.g. another of your threads) until either they are consumed or the consumer rolls back and they are made available to the queue again.

We use tibco and we turned off all prefetching as it was causing some erroneous behavior in certain situations...

[lkesteloot]

Spawning a thread in your on message handler is a very bad idea.

Why?

I'm not familiar with activemq but what you are describing sounds like a prefetch setting.

Yes, you're right. This is probably the fifth time I've run into unpleasant ActiveMQ behavior that was later attributed to prefetch. But it's the default setting, which means that turning it off runs ActiveMQ through infrequently-used code. I've had poor luck with such code in ActiveMQ. :-)

Lawrence