When the processor hits 100%, take a thread dump (actually, take several) and
see which thread(s) are running. That should narrow down the list of culprits.
Thread dump info:
http://www.jboss.org/wiki/Wiki.jsp?page=StackTrace
View the original post :
Hi Joachim,
Actually, I don't have the caching service active. (I don't have a
ejb3-caching-service.xml (or whatever it is)) in my deploy directory.
I am willing to buy that GC might be slamming the CPU, but the used ram is
always around 500MB, and I've allocated 2.25 GB of ram.
Is there
Hi Peter,
I'm trying to get that thread dump now, actually. I've changed the line in my
run.sh to read:
-Djava.endorsed.dirs=$JBOSS_ENDORSED_DIRS \
-classpath $JBOSS_CLASSPATH \
org.jboss.Main $@ /tmp/jboss.trace
All of the chatter is going to this file, however, when I do a kill
The method using JMX linked to at the top of the page is likely easier; note
the note further down the page of doing the dump via twiddle.sh from the
command line.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3973071#3973071
Reply to the post :
Taking a thread dump is a function of the JVM, not of JBoss. Perhaps JRockit
is placing the threadump somewhere else, like the IBM JVM does. You would have
the check the JRockit documentation for details. Or it might not even support
a thread dump, in which case I suggest trying the Sun JVM
Try redirecting standard error to the file as well:
-Djava.endorsed.dirs=$JBOSS_ENDORSED_DIRS \
-classpath $JBOSS_CLASSPATH \
org.jboss.Main $@ /tmp/jboss.trace 21
And check that you are sending kill -3 to the correct java process.
View the original post :
Hi Scott, Peter, and Taylor,
I switched back to the Sun JVM and redirected stderr, and it works now. Now for
the fun part: waiting for everything to blow up.
I'll post more details as they come.
thanks so much,
JLS
View the original post :
