Rather than making the change in BaseAppender, I've made it in SocketAppender. My reasoning is that the "standard" implementation of prepareForDeferredProcessing in logback-classic's LoggingEvent is to eagerly grab/compute the formatted message, the MDC and the thread name. For at least the formatted message, this appears to be a conscious choice. For example, in LOGBACK-495 the decision was made to delay the creation of the formatted message in part to improve performance.
In particular, the CyclicBufferAppender or AsyncAppender might be used to drop events under high load rather than backlog, and SMTPAppenderBase might choose to not log a message at all. Moving prepareForDeferredProcessing into the root AppenderBase and UnsynchronizedAppenderBase classes could decrease performance for certain use cases.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
I've submitted a pull request for this issue (https://github.com/qos-ch/logback/pull/274).
Rather than making the change in BaseAppender, I've made it in SocketAppender. My reasoning is that the "standard" implementation of prepareForDeferredProcessing in logback-classic's LoggingEvent is to eagerly grab/compute the formatted message, the MDC and the thread name. For at least the formatted message, this appears to be a conscious choice. For example, in
LOGBACK-495the decision was made to delay the creation of the formatted message in part to improve performance.In particular, the CyclicBufferAppender or AsyncAppender might be used to drop events under high load rather than backlog, and SMTPAppenderBase might choose to not log a message at all. Moving prepareForDeferredProcessing into the root AppenderBase and UnsynchronizedAppenderBase classes could decrease performance for certain use cases.