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 <jeffrey.se...@gmail.com> wrote: > 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 < > qu...@pronoia-solutions.com> 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 <jeffrey.se...@gmail.com> >> 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 >> >> >
