Hi, first, you can use JMX on the broker to disconnect the connection of the hanging consumer. But this is a very rude work-around, of course.
We had a similar issue connecting with Java-based consumers. We seem to have found a work-around by disabling caching and tight encoding on the OpenWire wire-format by using "wireFormat.cacheEnabled=false&wireFormat.tightEncodingEnabled=false". We haven't had no issue in production for almost 10 days now, whereas we had one once every day before the settings change. I don't know if NMS also supports those options, if yes, you might want to give them a try. Best regards, Martin On Tue, Aug 16, 2011 at 11:17 PM, Frank Gynnild <fr...@gynnild.com> wrote: > Hi everyone > > The problem: > I have a random issue using ActiveMQ 5.5 and the latest NMS library from > .NET. > A unit test creates and sends 1 000 000 messages of random size. > Simultaneously > a consumer tries to pick up these messages as fast as it can. Most of the > times > all messages are received as expected, but every now and then this situation > occurs: > 1) After x number of messages, the consumer stops picking up messages. > 2) The producer continues to send messages until all messages are sent. > I've also tried it from different machines, and the problem occurs randomly. > > The symptoms: > - When this occurs, browsing messages on the queue in the ActiveMQ console, > shows no messages on the queue (the number of pending messages are there, > but the list of messages can't be viewed). > - There's no error or trace in the ActiveMQ log when this happens. > > Workaround: > - The only way I've found to recover from this situation is to restart the > ActiveMQ. > - In the ActiveMQ log, I always see these lines: > 2011-08-16 22:54:49,848 | INFO | Recovering from the journal ... | > org.apache.activemq.store.kahadb.MessageDatabase | main > 2011-08-16 22:54:49,849 | INFO | Recovery replayed 1 operations from the > journal in 0.109 seconds. | org.apache.activemq.store.kahadb.MessageDatabase > | main > - The unit test pick up from where it left and completes (I'm using the fail > over protocol). > > Is this a known bug? Is there a work around that doesn't involve restarting > the ActiveMQ service? > > Best regards, > Frank > >
