Problem
Depending on the situation, you may find error traces in the APM UI that do not include stack traces for your Java app.
Solution
Depending on the situation, follow these troubleshooting procedures.
- No stack traces for rapidly repeated errors
-
When an error is thrown in a rapidly repeated sequence, the Java compiler may optimize the stack trace away to help performance. To disable this optimization: In your JVM flags, include:
-XX:-OmitStackTraceInFastThrow
- No stack traces for 500 errors
-
This is normal behavior for how the Java agent handles 500 errors. To force stack traces to be reported, call the New Relic Java API from your own code. Running the
NewRelic.noticeError (Throwable t)
method will cause an error to be reported along with the stack backtrace represented by theThrowable
. For more information about this method and its overloads, see New Relic's Java agent API on GitHub.
Cause
Returning a 500
error means that the application server itself detected an error and set the HTTPS 500
status code.
- If the error condition was detected and handled by application logic, there was no exception object and thus, no stack.
- If there was an exception object at some point, but it was handled internally by the application code that set the
500
status on the response, then the exception never became visible to the Java agent. There is no stack available for the Java agent to report.
When stack traces are reported, the error results from an exception that was not caught and handled within the application server logic. The Java agent sees the unhandled exception during a monitored transaction, so it reports the stack trace.
However, no stack traces appear for the 500
errors because the application server is handling the errors and then setting the status code. The application code itself does not retain any stack traces.