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.
