From: "Adam Heath" <[email protected]>
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.
Yes I just checked, it's 64bits. Hopefully my setting will be ok, even for 2 instances (we will have to use the same on the stable
version...). Anyway right now we can't physically do
better.
Jacques
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.
