We are experiencing an OutOfMemoryError when using MirroredQueues and I was wondering if someone could comment on whether our use (or interpretation) of these Mirrored Queues is correct, or if there is a bug in the BrokerService code.
In our case, we have an existing application “A” that uses messaging, but we now have a new application “B” that will only sometimes monitor the messaging on the original application “A”. We don’t want the first application “A” to have to know about, or to do anything different if application “B” is there listening to the messages or not. This seemed like a decent use of MirroredQueues (since they evidently create a “topic” that can be used as a wire-tap), but evidently by setting BrokerService.setUseMirroredQueues(true) on the broker for Project “A”, we’ve introduced a rather large memory leak. The objects that appear to grow in number are: org.apache.activemq.store.memory.MemoryTransactionStore$2 org.apache.activemq.store.memory.MemoryTopicMessageStore org.apache.activemq.command.ActiveMQTopic This seems to suggest the mirrored messages are being retained, but the Broker has setPersistent(false) specified and I don’t see any way to set Time to Live, or any other way for the Broker to monitor and remove if necessary on the Mirrored Queue only, etc.. If I look at the queues via jConsole MBeans, I can see the Topic.VirtualTopic.Mirror.DacIncomingQueue with attributes showing that the messages are only being enqueue and not dequeued. I really want the Broker to drop these messages if Application “B” is not there to dequeue them. Is it recommended that we use MirroredQueues to do this? If so, what’s the best way to set things up so I don’t have a memory problem if the other application is not listening to the mirroredQueue? … and if not, we would appreciate any other suggestions. ---- For attached Example Code---- The code attached is a simplified version of our Project “A” only and represents the case where Project “B” is not online (and not included in this example at all in fact) … it does show our use of Spring Templates to set up the Broker (and the producer and consumer clients). I’ve tried to remove quite a bit of the extraneous stuff to try to get it down to the basic problem, but I apologize that it still has a bit of fluff. I’ve also arranged things such that the broker is in a separate JVM to more easily see the memory growth of this component. The BrokerService is specified in the jms.broker.BrokerBean class. For the attached code and the 8MB specified for the JVM, we get about 3542 messages before the broker dies with an OutOfMemoryError I’ve also noticed that there is a BrokerService.setUseTempMirroredQueue() method and wonder if that is more appropriate for my use since it implies that the Mirrored Queue will be temporary, but the JavaDoc for this message is empty and I’ve seen nothing on the forums as to its characteristics and proper use. When I do use the Temporary Mirrored Queues, I also don’t see the same Virtual Topic that should be created that I see with the regular MirroredQueue topic (i.e. I don’t see VirtualTopic.Mirror.Foo.Bar being created for a queue of Foo.Bar), so this doesn’t seem to fit our needs. If you want to run the code, run jms-broker first, then run jms-client (client contains both a message producer and consumer). There is a README.txt file in the top level directory of each application for build and execution instructions. Using ActiveMQ 5.2.0 and Spring 2.5.4 on a Windows XP SP2 platform (but we’ve seen this on unix platforms as well) and I’ve been using jconsole, and jvisualvm to monitor memory growth and queues http://www.nabble.com/file/p22688889/jmsMirroredQueueExample.zip jmsMirroredQueueExample.zip -- View this message in context: http://www.nabble.com/Use-of-MirroredQueues-results-in-OutOfMemoryError-tp22688889p22688889.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
