camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ee7arh <andrew.hu...@2e-systems.com>
Subject Re: References to objects processed in routes held, eventually run out of memory
Date Thu, 19 Mar 2009 13:39:42 GMT

Hi,

Thanks but we are not using camel-jaxb, everything is being done manually
using the JaxB classes directly (although now I see camel has this built in
I will change.... well for R2.0 anyway!)

As way of double checking, I found only 7 instances of my unmarshalled
objects in the memory dump, not 1600 like I see for the aforementioned
object in previous post.

Andrew


Claus Ibsen-2 wrote:
> 
> Hi
> 
> Just a very quick reply without digging into it yet. There was/is a
> leak in camel-jaxb.
> I cant remember if we got it fixed in 1.6.0 or its in 1.6.1. At least
> its fixed in 2.0m1.
> 
> Could you either:
> - try without any JAXB
> - try with 1.6.1-SNAPSHOT or 2.0m1/2.0-SNAPSHOT
> 
> 
> 
> On Thu, Mar 19, 2009 at 2:24 PM, ee7arh <andrew.hurst@2e-systems.com>
> wrote:
>>
>> Hi,
>>
>> Thanks for response.
>>
>> I'm using Camel 1.6.0 and ActiveMQ 5.2.0. I also had the same results
>> with
>> camel 1.5 and activeMQ 5.1
>>
>> I have attached a graph from Jconsole showing what happens as the
>> application starts, runs for a about 1.5 hours then crashes with out of
>> memory. http://www.nabble.com/file/p22600122/jconsole-graphs.jpg
>>
>> Notes:
>>
>> - I set the maximum memory to 64MB using -Xmx64M -server. normally I
>> would
>> use more but then the problem takes longer to reproduce
>> - Notice the number of loaded classes never reduces. I also have another
>> application which shows the same pattern.
>> - As the application starts to run out of memory, the CPU usage goes
>> extremely high
>>
>> Here is my route:
>>
>> from("jms:queue:mobileExtTriggerInvites")
>>
>> .errorHandler(deadLetterChannel("seda:errors").maximumRedeliveries(0))
>>
>>            // Exception Handling
>>            .onException(JAXBException.class)
>>                .to("jms:queue:unmarshallableRequest").end()
>>            .onException(UnexpectedEventException.class)
>>                .to("jms:queue:unexpectedEvent").end()
>>
>>            // Log Incoming XML
>>            .to("log:incomingEventXmlLogger?level=INFO")
>>
>>            // Attempt to Unmarshall object expected on this queue
>>          
>>  .to("bean:eventMarshaller?methodName=unmarshallTriggerInvites")
>>
>>            // Generate Service Events from this External Event
>>
>> .to("bean:serviceEventGenerator?methodName=procecssTriggerInvites")
>>
>>            // Split generated Events out of List into individual events
>>            .splitter(body())
>>
>>        // Destination queue for further processing
>>        .to("jms:queue:serviceEventQueue");
>>
>> You can see that I have 2 bean processors, I have also attached the code
>> for
>> those.
>>
>> http://www.nabble.com/file/p22600122/EventMarhaller.txt
>> EventMarhaller.txt
>> http://www.nabble.com/file/p22600122/ServiceEventGenerator.txt
>> ServiceEventGenerator.txt
>>
>> Perhaps it's useful, perhaps not but I read a blog article which sounded
>> very similar to the problem I am having, link below. Basically it looks
>> like
>> Camel or ActiveMQ still has a reference to every single object I create
>> and
>> send through the routing - this would surely explain why the number of
>> loaded classes gets bigger and bigger the more the application runs.
>>
>> http://dertompson.com/2007/08/01/fighting-the-outofmemoryerror/
>> http://dertompson.com/2007/08/01/fighting-the-outofmemoryerror
>>
>> using JConsole, I also periodically purged the end queue and this made no
>> difference.
>>
>> If it helps, I am able to provide a heapdump to anyone for analysis with
>> jHat. As mentioned in my 1st post, all instances of classes created
>> during
>> the application lifecycle continue to live on in memory. It appears that
>> my
>> objects are referenced by ActiveMQMessage
>>
>> For example, I will trace 1 of those classes created in code attached:
>>
>> Class:
>> class
>> com.ee.berbe.mobile.servicelogic.flightops.events.service.TriggerMMSInvitations
>>
>> References to this object:
>> org.apache.activemq.command.ActiveMQObjectMessage@0xafab8fd8 (174 bytes)
>> :
>> field object
>>
>> --> -->
>>
>> Class:
>> class org.apache.activemq.command.ActiveMQObjectMessage
>>
>> References to this object:
>> java.util.LinkedHashMap$Entry@0xafab8970 (32 bytes) : field value
>> java.util.LinkedHashMap$Entry@0xafab8810 (32 bytes) : field value
>>
>>
>> So it seems that ActiveMQ is still storing all my objets on a
>> LinkedHashMap
>> but I've no idea why.
>>
>> Thanks again for any help
>>
>> Andrew
>>
>>
>> willem.jiang wrote:
>>>
>>> Hi
>>> Which version of Camel are you using ?
>>> Can you show us you routing rules and your processor codes?
>>>
>>> They will help us to dig the issue.
>>>
>>> Willem
>>>
>>>
>> --
>> View this message in context:
>> http://www.nabble.com/References-to-objects-processed-in-routes-held%2C-eventually-run-out-of-memory-tp22580791p22600122.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
> 
> 
> 
> -- 
> Claus Ibsen
> Apache Camel Committer
> 
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> 
> 

-- 
View this message in context: http://www.nabble.com/References-to-objects-processed-in-routes-held%2C-eventually-run-out-of-memory-tp22580791p22600424.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Mime
View raw message