This is really only a problem that (normally) occurs with lots of redeploying without restarting the entire app server. I'm speculating a bit, but I believe with GAE they start a new (separate) instance when you deploy, which effectively prevents you from running into PermGen errors.
How errors like this occur is fairly simple - if something outside your application holds on to a reference to something inside your application, it will cause the classloader to leak and after enough redeployments, you will run out of PermGen space. The most common culprit from what I have seen is a database driver being bundled with your application, and some libraries can also cause odd issues in this area. I'm not enough of an expert with classloaders and the like to know where, exactly, the fault lies - but I'd probably guess that the complexity of the ClassLoader, as you suggest, is part of the problem. I'm not sure if this is something that will change at all in Java 7 - anyone have any idea? As for how to track down a PermGen error - if you have eliminated all of the usual suspects, you can start your app server, deploy your app, undeploy it, and then get a heap dump. In the heap dump, find the classloader object for that application (in Tomcat and Jetty, it is an instance of WebAppClassLoader I believe - not sure what it is on GlassFish) and then find the references to that object. It isn't always incredibly straightforward or easy, but if you are getting serious heartburn from PermGen issues, it may be worth a shot. - Spencer On Dec 19, 8:45 am, Casper Bang <[email protected]> wrote: > I won't even try to pretend that I understand all the intricate > details of the class loaders, GC and leakage. However you turn and > twist it, it's a design issue somewhere between the JVM and the > application server concept (accidental complexity?). And it's one hell > of a good reason to run your app as an embedded Grizzly or Jetty > instead - much more predictable. Now what I would REALLY love to know, > is how on earth is GAE handling this?! > > /Casper > > PS: I have never seen something a kin to PermGenSpace on .NET and I > assume this is due to the fact that they took a more KISS attitude (no > custom low-level class loader, only dynamic assembly modules > responsible for their own mess). > > On Dec 19, 5:49 am, Brian Leathem <[email protected]> wrote: > > > On 18/12/09 3:44 AM, Casper Bang wrote: > > > > All good points. Startup time with 15-20 applications deployed would > > > also be more interesting than pure container startup - given how that > > > can easily take 5+ minutes, a long time in a production environment > > > which just suffered from PermGenSpace problems and had to be > > > restarted. > > > How *do* you get rid of those PermGenSpace problems (aside from > > increasing the PermGenSpace). I get them often and have to completely > > restart Glassfish/Netbeans to get back to normal. This can take a > > while, as Glassfish doesn't stop nicely when it runs out of PermGen. > > > I made significant improvements by moving some of my 3rd party Jars into > > the app server lib folder, so that those classes wouldn't have to be > > re-loaded with every re-deploy. But it still happens. > > > Maybe with GF v3 finally having support for compile/deploy on save for > > maven projects, I'll finally escape this problem. > > > Brian Leathem -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
