activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Teira <mte...@tid.es>
Subject Re: ActiveMQ Causing OutOfMemoryError After Service Deployment in ServiceMix
Date Wed, 25 Jul 2007 06:17:52 GMT
ArmenH escribió:
> Thanks Manuel,
>
> Which version of ActiveMQ includes your fix?  Please provide the exact
> version.
>   
No official release yet. It should be the 4.1.2 release, as AMQ-1319 was 
kindly resolved and the patch applied just yesterday by Jonas Lim.
> Also, do the ServiceMix folks know about this fix and would it be included
> in the next ServiceMix SNAPSHOT ?
>   
Sorry but I'm not sure about the source relationships among ServiceMix 
and amq. I think that ServiceMix just relies in amq for all the 
messaging stuff, but how they synchronize on versions is a mistery to me.

Regards.

> Armen H.
>
>
> Manuel Teira-2 wrote:
>   
>> Hello.
>>
>> Your problem have the same symptoms that the one I've notified as 
>> AMQ-1319 if you're using activemq 4.1.x or a lower version. 
>> DestinationMapNode is not correctly erasing all the references 
>> (specifically the 'anyNode' nodes) of the map and so, leaking also Topic 
>> references and all the related stuff.
>>
>> If this is the same problem, you shoudn't suffer it under 5.0 or under 
>> 4.1 with the patch I've attached to AMQ-1319.
>>
>> Regards.
>>
>>
>> ArmenH escribió:
>>     
>>> We have found out that after just one service deployed on Windows
>>> ServiceMix
>>> the memory usage jumps to 500 MB and it increases linearly after each
>>> service deployment until ServiceMix dies with an OutOfMemoryError.
>>>
>>> We tried increasing the heap size and it helped up to a certain number of
>>> services deployed in the container, after that the Error happened as
>>> expected.
>>>
>>> We used jhat for heap analysis and found out that the following instance
>>> usage (after just one service deployment):
>>>
>>>
>>> 1673478 instances of class org.apache.activemq.filter.DestinationMapNode
>>> 3001 instances of class
>>> edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantLock$NonfairSync
>>>
>>>
>>> This is a critical issue for us.  We'd like to limit the number of
>>> instances
>>> created on the heap. Please advise.
>>>
>>> Regards.
>>> Armen H.
>>>   
>>>       
>>
>>  
>>
>>     
>
>   


Mime
View raw message