activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Trace Level Logging For Lost Messages
Date Tue, 24 Apr 2007 07:21:19 GMT
On 4/19/07, greenbean <> wrote:
> We are using Activemq 4.1.1 with Stomp.  We can reproduce a condition where
> it appears messages are lost.  However, we would like to trace the internal
> flow of messages to see exactly what is happening.  With a standalone
> Activemq instance running, adjusting to debug as suggested
> online and in the properties file produces very little logging about what is
> happening.  Is there a better way to get very detailed logging information?

We welcome patches if you want to try alter the logging behaviour to
expose more information you need.

> We appear to lose messages when we have around 100 Stomp consumers
> distributed to several machines consuming from a single queue using
> different message selectors.  The remote consumers send a message to another
> queue after processing the data in the message they consumed.  There are
> multiple processes producing messages that are consumed by the remote
> consumers.
> Things appear to work fine until a simulated level of parallelism reaches a
> certain point.  This means each producer process produces, say, 24 messages
> with different header properties for consumption by remote consumers with
> specific message selectors instead of 10 messages with different header
> properties.  A point is reached after a couple of cycles of production and
> consumption where activemq stops functioning.  Messages are no longer
> delivered after this point.  Using a test driver to send a message to a
> queue appears to send a message.  However, the message is not delivered, and
> the queue size shown through JMX does not increase.  Once Activemq enters
> this state, the only way to correct the issue is to stop activemq, and
> restart it.  However, the problem appears again after a couple more cycles
> of production and consumption of messages.
> Any suggestions or help on tracking this issue would be great.

When things seem to hang, I wonder if there's some kinda deadlock
found? e.g. could you try create a thread dump to see if there's a

Also its sometimes worth experimenting with StompConnect with
ActiveMQ; which is an alternative Stomp transport using the JMS API
underneath to see if it has the same issues. As this could help to
track down a specific issue with the native Stomp transport for


View raw message