You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by bu...@apache.org on 2010/03/16 12:50:42 UTC

DO NOT REPLY [Bug 47740] log4j 1.2.15 deadlock RootAppender NDC

https://issues.apache.org/bugzilla/show_bug.cgi?id=47740

--- Comment #3 from Petr <ho...@post.cz> 2010-03-16 11:50:39 UTC ---
I looked at the thread dump provided and actually I don't see any classic
deadlock there.

What can be seen there is that some native thread holds a monitor lock on that
hashtable so all those threads are waiting for it. It could be because of
garbage collection run for example.

I've seen the similar behavior on HP JVMs (but on HP-UX) many times before and
it was almost always caused by garbage collections running repeatedly.
I noticed that in many cases (full heap, can't be GC'd) the HP JVM doesn't
throw OutOfMemoryError but instead ends up in endless garbage collection cycle.
This happens especially (maybe only - I'm not sure) if parallel GC is used
which is the default for multi CPU systems.

What can you do is to run the JVM with verbose GC (on HP JVM it's like
-Xverbosegc:file=/tmp/java-something.vgc ) and when you notice such behavior
again have a look at the vgc file with HPjmeter for example. This will tell you
if your JVM ends up in that GC loop.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org