This was an interesting issue.
We were seeing exceptions in log with empty traces, this was happening even though we had done logger.error(e); or e.printStackTrace.
Our CTO found out that aparently its some JVM optimization by sun (now oracle lol).
From http://java.sun.com/j2se/1.5.0/relnotes.html
he found
<<<
The compiler in the server VM now provides correct stack backtraces for all "cold" built-in exceptions. For performance purposes, when such an exception is thrown a few times, the method may be recompiled. After recompilation, the compiler may choose a faster tactic using preallocated exceptions that do not provide a stack trace. To disable completely the use of preallocated exceptions, use this new flag: -XX:-OmitStackTraceInFastThrow.
>>>
Kudos to him as we were thinking its some DWR library issue eating the trace.
We were seeing exceptions in log with empty traces, this was happening even though we had done logger.error(e); or e.printStackTrace.
Our CTO found out that aparently its some JVM optimization by sun (now oracle lol).
From http://java.sun.com/j2se/1.5.0/relnotes.html
he found
<<<
The compiler in the server VM now provides correct stack backtraces for all "cold" built-in exceptions. For performance purposes, when such an exception is thrown a few times, the method may be recompiled. After recompilation, the compiler may choose a faster tactic using preallocated exceptions that do not provide a stack trace. To disable completely the use of preallocated exceptions, use this new flag: -XX:-OmitStackTraceInFastThrow.
>>>
Kudos to him as we were thinking its some DWR library issue eating the trace.
Nice catch. Keep posting such catch-things which roughly I think 95% or Java programmers don't know about, it makes avg developers level higher! :)
ReplyDelete