2

I have a Mule instance running with numerous RSS Connectors, and I have a service running within the same Mule context that receives RSS feed updates/deletes/additions. When something with a feed changes, that service triggers a hot deploy by touching the Mule config file. That works fine. Mule reloads the context and picks up the changes.

However, every time I do a hot deploy, the class loader reloads almost all classes, almost duplicating the initial PermGen memory footprint every time. Eventually, I run out of PermGen space, and Mule crashes. It doesn't matter how big I make it - every hot deploy demands more space. I'm monitoring this in YourKit, FWIW.

I found some generic information about making servers use shared libraries, instead of loading new ones in every context. I assume what's happening is that each time a hot deploy occurs, a new Mule context is created, and Mule reloads all the classes into the new context instead of using the ones that were already loaded.

How can I do multiple hot deploys without running out of PermGen?

Thanks!

kash
  • 199
  • 2
  • 7
  • Only your project classes should be reloaded, all the other classes (like the Mule ones, the transport ones) should not. Do you have a lot of classes or JARs in your application? – David Dossot Nov 05 '14 at 04:16
  • You are likely correct that only my classes are reloading and taking up more memory each time. There are 170 jars totaling 66M, compressed/on disk, in this particular app. – kash Nov 05 '14 at 14:05
  • Wow 170 JARs? Are you, by accident, packaging the Mule JARs in the application? – David Dossot Nov 05 '14 at 15:47

2 Answers2

1

Try adding "-XX:PermSize=128M -XX:MaxPermSize=256M" in your Run Configuration->Arguments tab-> VM arguments

Vihar
  • 3,626
  • 2
  • 24
  • 47
  • 2
    Since every hot deploy increases the memory taken up by the classes/class loader, it doesn't matter how big I make the PermGen. It will eventually run out of space. I've had it configured as high as 1024m, and it will eventually fail with enough hot deploys. – kash Nov 05 '14 at 13:58
0

Based on advice from co-workers who have worked directly with Mule support, it seems that using hot deploy, except for occasional restarts, is not a good or reliable practice. They were discouraged from using it; instead, it was recommended that they restart the whole Mule server.

That was not a good option for me either. However, it turned out that creating new Mule contexts every time I needed to add new flows worked just fine. I just create the context, add my new flow, and then start the context. Simple, fast, and clean.

The DefaultMuleContextFactory worked fine for me. If you have special needs, you might need to use a ConfigurationBuilder.

Example:

MuleContext newMuleContext = new DefaultMuleContextFactory().createMuleContext();
MuleRegistry registry = newMuleContext.getRegistry();
Flow flow = createFlow();
registry.registerFlowConstruct(flow);
newMuleContext.start();

Note that this was in Mule 3.4.0, but I also tested my original problem in 3.5.0 and had the same problem. This fix worked for both.

kash
  • 199
  • 2
  • 7
  • Still, 170 JARs in your app/lib... it smells like a build issue (for ex, adding Mule deps at compile scope instead of provided scope). – David Dossot Nov 06 '14 at 17:58