On Jan 11, 2007, at 6:08 PM, Christopher M. Cardona wrote:
Rakesh Midha wrote:
Hello Chris,
Is there some specific scenerio where you are getting java heap
space error.
What I am guessing is that there can be a scenerio where
classloaders are cyclic. Is it possible, that
Classloader C1 is a parent of Classloader C2
Classloader C2 is a parent of Classloader C3
Classloader C3 is a parent of Classloader C1
As David Jencks pointed out this is not allowed. I was wondering if
our implementation enforces this. There are no specific steps to
replicate the problem but I usually get it after reloading
Classloader viewer portlet and doing searches a couple of times. So
I’m guessing something is not being garbage collected or there’s a
memory leak somewhere. I'll try to rebuild and see if it makes any
difference.
It doesn't look like the problem is a memory leak. If you bump your
max heap a bit, I don't think you'll see the problem (e.g. export
JAVA_OPTS=-Xmx96m). The ClassLoader seems to be quite memory hungry.
I haven't looked to see what's going on, but would hope we could trim
things down a bit and be a little more efficient...
BTW, I found another problem with the JNDI viewer portlet. After
deploying a standalone ejb jar I get a NullPointerException when
viewing the portlet. My guess is you forgot to consider the case
where an ejb module is deployed and it’s not inside an ear file
resulting to a null J2EE application.
Thanks for pointing this out.
Safari isn't working very well with these views. I get "Maximum call
stack exceeded" errors in the Javascript console. However, things
work ok (provided the server has enough memory) from Firefox and IE...
I'd like to commit what we have ATM and start addressing these issues
(memory, ejb jar, plugability) as bug fixes/enhancements. Anybody
feel strongly otherwise?
--kevan
