[HADOOP-3654] Log4J logging of stack trace may deadlock JRockit in TestFileSystem

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Later
• Affects Version/s: 0.19.0
• Component/s: conf

Environment

Ubuntu 8.04 x86_64 4-way running java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
BEA JRockit(R) (build R27.4.0-90-89592-1.6.0_02-20070928-1715-linux-x86_64, compiled mode)

Linux 2.6.22-15-generic #1 SMP Tue Jun 10 08:52:15 UTC 2008 x86_64 GNU/Linux

• Assignee: Unassigned
• Reporter: Steve Loughran
• Created: 27/Jun/08 14:59
• Updated: 29/Apr/10 08:07
• Resolved: 24/Dec/09 12:44

Description

This is being added as a bugrep so that other people can find it, and the workaround

1. On my machine TestFileSystem will hang, even overnight -even though the build was set with a timeout.
2. halting the build left a JVM running; it was not being killed.
3. Under the IDE, the main thread appears hung in the native library call to get a stack trace, somewhere inside Log4J
4. the IDE could not halt the build, and could not be shut down cleanly either

The fix for this problem was to edit conf/log4j.properties and switch to a log4J log pattern that did not print the line of the code

log4j.appender.console.layout.ConversionPattern=%-4r %-5p %c %x - %m%n

Given that working out a stack trace can be an expensive call, and that it can apparently hang some JVMs, perhaps it should not be the default.