Stacktraces need to provide value, otherwise they just waste log space. So whether or not a stack trace should be printed should be based on whether it is going to provide value or not. Otherwise, just logging the exception message and class would be fine.
Remember, the original message was going through the “normal” logging system. Errors in an appender should get logged via StatusLogger, which does not have the flexibility the main logging system does in formatting output, so you can’t print the stack trace and then configure it to just print a few lines. I would suggest that the code should be modified to catch the exception and gracefully handle it. The part I don’t understand is that the AppenderControl should be catching the exception so I don’t know why that would kill the thread, unless the Throwable is an Error. Ralph > On Jun 17, 2020, at 7:34 AM, Volkan Yazıcı <[email protected]> wrote: > > Hello, > > Yesterday I've paged by a colleague for a really strange logging > behaviour on production. The logging stops working after 15m-2h. > Diving into Tomcat catalina logs pointed out that there is a > particular exception whose Throwable#printStackTrace(PrintWriter) > method is throwing an exception -- causing the death of the appender > thread, which is another issue actually. That is, trying to dump an > exception is causing an exception. This got me thinking about the > question in the subject: How shall a Layout handle stack trace > serialization failures? Dump the 2nd exception instead? Any ideas? > > Kind regards. >
