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 > >
