activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jvh <jhuffna...@comcast.net>
Subject Re: Use of MirroredQueues results in OutOfMemoryError
Date Mon, 30 Mar 2009 18:20:10 GMT

Yep, I think that's got it!  I've been testing from rev. 759125 (3/27) and I
don't see the build-up of those objects anymore.  I'll see about integrating
this 5.3-SNAPSHOT into our stuff.

Thanks,
--jim


Andreas Gies-3 wrote:
> 
> Hello,
> 
> I have just rerun the testcase against the latest trunk and the  
> problem does not occur anymore. I have let the test run
> for about a million messages.
> 
> Ig you have time, perhaps you can double check this ?
> 
> Best regards
> Andreas
> 
> 
> On Mar 26, 2009, at 5:41 PM, Andreas Gies wrote:
> 
>> Hi there,
>>
>> I apologize for not heaving read all the information from the  
>> beginning - I shouldn't answer mails while traveling ;)
>> I could reproduce the problem using your test case in both AMQ 5.2  
>> and the current trunk.
>>
>> I have made the same observations regarding the objects that are  
>> growing in number. As a side issue, the reported
>> number via jconsole regarding the Queuesize is misleading. There are  
>> actually no messages available for delivery
>> even if the queue size shows a number > 0. I believe there is an  
>> open issue regarding that misleading metric:
>> http://issues.apache.org/activemq/browse/AMQ-1600
>>
>> I think that explains why you see a queue size > 0.
>>
>> This having said, a very brief look at the code, the interceptor  
>> dealing with Mirrored queues simply recreates
>> the send ProducerExchange and calls the delivery for that. Why the  
>> memory leak occurs here, but not with
>> a "normal" publisher to a topic with no subscribers, is not yet  
>> clear to me. Perhaps someone else can jump in here.
>>
>> I think for now it would be best to create a JIRA and attach your  
>> test case if possible, so that we can track that properly.
>>
>>
>> Best regards
>> Andreas
>>
>>
>>
>> On Mar 25, 2009, at 3:00 PM, jvh wrote:
>>
>>>
>>>
>>> We're using activemq-all-5.2.0.jar ... more information is listed  
>>> at the
>>> bottom of the original post.
>>>
>>>
>>> Andreas Gies-3 wrote:
>>>>
>>>> Hi there,
>>>>
>>>> which version of Active MQ are you using ?
>>>>
>>>>
>>>> Regards
>>>> Andreas
>>>> On Mar 24, 2009, at 9:20 PM, jvh wrote:
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> ---
>>>> Mit freundlichen Grüssen - Kind Regards
>>>> Andreas Gies
>>>> Principal Consultant
>>>> Open Source Center of Competence
>>>>
>>>> Progress Software GmbH
>>>> Agrippinawerft 26
>>>> 50678 Köln
>>>>
>>>> E-Mail      	agies@progress.com
>>>> Direct Line 	+49 (0)9953 980349
>>>> Mobile      	+49 (0)170 5759611
>>>> Skype        	+44 (0)20 3239 2922
>>>> Skype       	+353 (0)1 443 4971
>>>> Skype       	+1 (0)781 262 0168
>>>>
>>>> http://www.progress.com
>>>> http://fusesource.com
>>>> http://open-source-adventures.blogspot.com
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> Progress Software GmbH
>>>> Sitz der Gesellschaft: Agrippinawerft 26, 50678 Koeln;
>>>> Niederlassung: Fuerstenrieder Str. 279, 81377 Muenchen
>>>> Amtsgericht Koeln, HRB 15620;
>>>> Geschaeftsfuehrung: David Ireland
>>>> -------------------------------------------------------
>>>>
>>>>
>>>
>>> -- 
>>> View this message in context:
>>> http://www.nabble.com/Use-of-MirroredQueues-results-in-OutOfMemoryError-tp22688889p22702274.html
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>
>>
>> ---
>> Mit freundlichen Grüssen - Kind Regards
>> Andreas Gies
>> Principal Consultant
>> Open Source Center of Competence
>>
>> Progress Software GmbH
>> Agrippinawerft 26
>> 50678 Köln
>>
>> E-Mail      	agies@progress.com
>> Direct Line 	+49 (0)9953 980349
>> Mobile      	+49 (0)170 5759611
>> Skype        	+44 (0)20 3239 2922
>> Skype       	+353 (0)1 443 4971
>> Skype       	+1 (0)781 262 0168
>>
>> http://www.progress.com
>> http://fusesource.com
>> http://open-source-adventures.blogspot.com
>>
>>
>>
>> -------------------------------------------------------
>> Progress Software GmbH
>> Sitz der Gesellschaft: Agrippinawerft 26, 50678 Koeln;
>> Niederlassung: Fuerstenrieder Str. 279, 81377 Muenchen
>> Amtsgericht Koeln, HRB 15620;
>> Geschaeftsfuehrung: David Ireland
>> -------------------------------------------------------
> 
> ---
> Mit freundlichen Grüssen - Kind Regards
> Andreas Gies
> Principal Consultant
> Open Source Center of Competence
> 
> Progress Software GmbH
> Agrippinawerft 26
> 50678 Köln
> 
> E-Mail      	agies@progress.com
> Direct Line 	+49 (0)9953 980349
> Mobile      	+49 (0)170 5759611
> Skype        	+44 (0)20 3239 2922
> Skype       	+353 (0)1 443 4971
> Skype       	+1 (0)781 262 0168
> 
> http://www.progress.com
> http://fusesource.com
> http://open-source-adventures.blogspot.com
> 
> 
> 
> -------------------------------------------------------
> Progress Software GmbH
> Sitz der Gesellschaft: Agrippinawerft 26, 50678 Koeln;
> Niederlassung: Fuerstenrieder Str. 279, 81377 Muenchen
> Amtsgericht Koeln, HRB 15620;
> Geschaeftsfuehrung: David Ireland
> -------------------------------------------------------
> 
> 

-- 
View this message in context: http://www.nabble.com/Use-of-MirroredQueues-results-in-OutOfMemoryError-tp22688889p22789510.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message