camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Segal <>
Subject Re: Memory management
Date Tue, 26 Apr 2016 16:19:23 GMT
I dove a bit deeper and found the culprit: I added a few browse endpoints
as unit test hooks a few days ago. When I look at the cumulative incoming
references in JProfiler for the Strings that were lying around and drilled
down a bit, I saw that the vast majority were being held by
BrowseEndpoints, despite the fact that according to JMX, we had no
in-flight exchanges. I'm not sure if this is as-expected for the Browse
endpoint given that it's meant as a debugging tool or would actually be
considered a memory leak. In any case, I've since removed it and now my
heap has a very nice sawtooth pattern even under heavy load.

On Tue, Apr 26, 2016 at 10:30 AM, Jeff Segal <>

> For a particular test run, I see a peak of about 1.4 GB of char[]
> instances (most of which appear to be JSON Strings), but then it settles
> back down to about half that size indefinitely (with a forced GC from the
> profiler or regular interval GCs). Of the 700 MB remaining char[]
> instances, 96% are referenced by DefaultExchange objects which are sticking
> around.
> For what it's worth, I'm using xmljson() for the conversion.
> On Mon, Apr 25, 2016 at 6:46 PM, Quinn Stevenson <
>> wrote:
>> If you force a GC after the activity dies-down, is the memory recovered?
>> > On Apr 25, 2016, at 4:01 PM, Jeff Segal <>
>> wrote:
>> >
>> > I've got a set of routes that make a bunch of web service calls in quick
>> > succession, convert the XML to JSON and then save the results off to
>> > MongoDB. This occurs on a scheduled basis (using the scheduler
>> component,
>> > configured to run every few hours typically).
>> >
>> > Functionally, it works great. But I've started looking into the memory
>> > usage and have a few concerns. Primarily, I've been able to cause linear
>> > heap growth by increasing my total data set to be processed. My
>> > expectations were that generally adding more calls would slow the
>> process
>> > down and cause higher spikes, but not linear memory growth over time.
>> When
>> > I dug deeper in JProfiler, I found that even after all the initial
>> activity
>> > died down for a given run (i.e., no more in-flight Exchanges), the
>> majority
>> > of my memory consumption was Strings being held in the 'in' property of
>> > DefaultExchange objects. This seemed strange since I expected those all
>> (or
>> > most) Exchanges to complete and be GC'd by that point (it holds steady
>> for
>> > long periods of inactivity).
>> >
>> > Is there an important cleanup step that I might be missing in my routes?
>> > I'd include them but they're pretty complex and might muddy the waters
>> here.
>> >
>> > Thanks,
>> > Jeff

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message