Update: This doesn’t seem to have completely fixed the problem, although perhaps I’m reloading the context to often for the garbage collector to keep up. I’ll keep you posted. Anyhoo, if you read this and try it out, please let me know if it works for you.
Anyone who develops Wicket applications and doesn’t have a bajillion gigabytes of RAM (and java command line options to match) eventually runs into the “Out of PermGen Space” issue. This happens because, by default, the JVM doesn’t reclaim this kind of memory.
For those of us who value the ability to hot-redeploy a context without bringing down our entire container (Geronimo, anyone?), the following JVM command-line options are invaluable:
Note that not all of them are necessary, but if you want to reclaim PermGen space you must have the last two at least.
I hope this helps someone else out there, this was caving my head in for a while before I realised the fix was so simple.
On another note, I have now read this Coderspiel article and am a convert to the world of individual Jetty containers running on their own VM. Memory’s cheap, right?
And, for my own 2c, Java frameworks are now so abstracted and separable that it’s possible to achieve 90% of what a full J2EE stack gives you just by cherry-picking a few bits and pieces (say, Hibernate + Wicket + Jetty). That gives you a much leaner, meaner stack and you can tune the Heck out of it.
Add Maven2 to the picture and you’re in pluggable, extensible, fire-and-forget heaven.
2 thoughts on “End the Wicket PermGen issue”
If you can, switch to JRockit. It’s garbage collection works better then Suns. You won’t get it anymore.
Dan, thanks for sharing this. My Wicket app went into PermGen as well after running smoothly for a while. I’ve run into PermGen issues with Spring/Hibernate stack but over there it occurred when we were adding more classes than the PermGen space permitted. Solution was obviously to increase the space but we always ran into PerGen while starting the application.
In contrast, the Wicket app went into PermGen after running for a while, which means that all classes must’ve been loaded but it was something else that caused the issue. I was wondering what scenario is causing PermGen in this case?
And as you’ve also written: “This happens because, by default, the JVM doesnâ€™t reclaim this kind of memory.”
What do you refer ‘this’ to?