camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From deckerego <>
Subject Re: Garbage collection Execuation ...
Date Mon, 12 Dec 2011 02:00:32 GMT
You can't force garbage collection to happen. You can /request/ that the JVM
invoke it's configured garbage collector when it's next possible to do so,
but a System garbage collection call is just a prompt and not a forced

Since JMX is enabled on your map, your best bet would be to use the garbage
collection profiling plugin of VisualVM. Watch which portions of the heap
grow - PermGen, Eden, Tenured, etc. That will tell you if you have leaks or
if you are constantly generating new objects and destroying them. It sounds
like you're rapidly marshalling objects, so I'm guessing it's the latter

If you have a large number of messages being concurrently marshalled than 2
GB isn't out of the realm of possibility. You may want to find the average
size of each message being marshalled - both its XML representation as well
as the size of the TCP packet. It's not uncommon for an XML message to be
10x the size of its bytecode representation.

It doesn't sound like you have a Camel issue per se, but more of an
application profiling issue.

atiato wrote
> Can you tell me how can I make garbage collection ? the camel context is
> attached , I didn't use any java code all in XML configuration .
> How can I minimize the memory usage to continue making stress testing ?
> should I use garbage collection from jconsole ? can you comment in the
> above command.
> Seems with Huge load u need independent Hardware , I 'm having SUN OS
> above .
> Camel context is attached .
> The camel routes is explained :
> From (TCP port) ---> Java Object--> Call WS --> return XML to TCP point as
> string .

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message