Jacques Le Roux wrote: > I found this link, not read yet > http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
While I haven't read that link before today(I just did right now), I am aware of such classes of problems. There was a similiar one ages ago in commons-dbcp. The basic crux of the problem is a static object that maintains a reference to anything created by a dynamically loaded method. This may not be a direct reference, but could be buried deep inside some nested collections-type structure. However, ofbiz doesn't redeploy it's things. Just because you run out of PermGen space, doesn't mean you have a memleak. You also have to consider whether the host is 32-bit or 64-bit. 64-bit hosts have larger permgen spaces. If you are explicitly setting the size, you might be missing out on the auto-sizing at startup of the vm. It's also just possible that ofbiz requires more permgen. I don't consider this a 'leak'. A leak of memory is a bug, wherein it's not ever possible to free the memory. Now, it may be we need to optimize, to reduce permgen usage, but over time, ofbiz will require more resources. It's just the nature of the game.
