[JIRA] Created: (LBCLASSIC-281) Don't evaluate formattedMessage in LoggingEvent constructor
Don't evaluate formattedMessage in LoggingEvent constructor ----------------------------------------------------------- Key: LBCLASSIC-281 URL: http://jira.qos.ch/browse/LBCLASSIC-281 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.29 Reporter: Andrew Brett Assignee: Logback dev list Whenever a ch.qos.logback.classic.spi.LoggingEvent is constructed, MessageFormatter.arrayFormat(...) is called, and the formattedMessage member variable assigned. This involves calling toString() on all arguments in argArray, which can be slow, and occurs even if the formattedMessage is not part of any appender layouts. For my project's purposes, I have a custom formatter which only outputs an abbreviated string form of certain objects with expensive toString() methods; however, I am still paying the overhead in the toString() calls, since they're made even when getFormattedMessage() is never called. Note that I don't control the source of the objects with expensive toString() methods, nor do I control the source everywhere they're logged, so I can't simply change them directly. formattedMessage is already evaluated lazily in getFormattedMessage(), so the only side effect of this change is the introspection of argsArray to look for a Throwable at the end, which is a trivial operation to perform separately. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-281?page=com.atlassian.jira.plugin.syste... ] Andrew Brett commented on LBCLASSIC-281: ---------------------------------------- Sorry for the inexact terminology above, when I say "custom formatter", I mean a class which implements ch.qos.logback.core.pattern.Converter, and is used as an alternative to ch.qos.logback.classic.pattern.MessageConverter - it doesn't simply return the formattedMessage, but instead looks at the types of objects in the argArray, and is able to call things other than toString() on those objects in certain cases.
Don't evaluate formattedMessage in LoggingEvent constructor -----------------------------------------------------------
Key: LBCLASSIC-281 URL: http://jira.qos.ch/browse/LBCLASSIC-281 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.29 Reporter: Andrew Brett Assignee: Logback dev list
Whenever a ch.qos.logback.classic.spi.LoggingEvent is constructed, MessageFormatter.arrayFormat(...) is called, and the formattedMessage member variable assigned. This involves calling toString() on all arguments in argArray, which can be slow, and occurs even if the formattedMessage is not part of any appender layouts. For my project's purposes, I have a custom formatter which only outputs an abbreviated string form of certain objects with expensive toString() methods; however, I am still paying the overhead in the toString() calls, since they're made even when getFormattedMessage() is never called. Note that I don't control the source of the objects with expensive toString() methods, nor do I control the source everywhere they're logged, so I can't simply change them directly. formattedMessage is already evaluated lazily in getFormattedMessage(), so the only side effect of this change is the introspection of argsArray to look for a Throwable at the end, which is a trivial operation to perform separately.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-281?page=com.atlassian.jira.plugin.syste... ] Richard Wheeldon commented on LBCLASSIC-281: -------------------------------------------- This is affecting a proposed new Appender we want to create as well - one which stores logging events then processes them only on certain conditions. It looks like the fix for LBCLASSIC-47 was either incomplete or subsequently reverted. Either way, it looks like it can be fixed by simply removing the two lines: {code} FormattingTuple ft = MessageFormatter.arrayFormat(message, argArray); formattedMessage = ft.getMessage(); {code} from the constructor.
Don't evaluate formattedMessage in LoggingEvent constructor -----------------------------------------------------------
Key: LBCLASSIC-281 URL: http://jira.qos.ch/browse/LBCLASSIC-281 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.29 Reporter: Andrew Brett Assignee: Logback dev list
Whenever a ch.qos.logback.classic.spi.LoggingEvent is constructed, MessageFormatter.arrayFormat(...) is called, and the formattedMessage member variable assigned. This involves calling toString() on all arguments in argArray, which can be slow, and occurs even if the formattedMessage is not part of any appender layouts. For my project's purposes, I have a custom formatter which only outputs an abbreviated string form of certain objects with expensive toString() methods; however, I am still paying the overhead in the toString() calls, since they're made even when getFormattedMessage() is never called. Note that I don't control the source of the objects with expensive toString() methods, nor do I control the source everywhere they're logged, so I can't simply change them directly. formattedMessage is already evaluated lazily in getFormattedMessage(), so the only side effect of this change is the introspection of argsArray to look for a Throwable at the end, which is a trivial operation to perform separately.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-281?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn commented on LBCLASSIC-281: ----------------------------------------- It's rather critical to evaluate/convert the arguments-array to strings during construction of the event/ASAP. (the actual formatting can be performed later) Otherwise, the objects in the argument array may change between the logging call and the actual processing of the message in an appender. Another example are LazyInitializationExceptions caused by Hibernate if an object isn't connected to the database session anymore. Both can be caused by an asynchronous appender implementation.
Don't evaluate formattedMessage in LoggingEvent constructor -----------------------------------------------------------
Key: LBCLASSIC-281 URL: http://jira.qos.ch/browse/LBCLASSIC-281 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.29 Reporter: Andrew Brett Assignee: Logback dev list
Whenever a ch.qos.logback.classic.spi.LoggingEvent is constructed, MessageFormatter.arrayFormat(...) is called, and the formattedMessage member variable assigned. This involves calling toString() on all arguments in argArray, which can be slow, and occurs even if the formattedMessage is not part of any appender layouts. For my project's purposes, I have a custom formatter which only outputs an abbreviated string form of certain objects with expensive toString() methods; however, I am still paying the overhead in the toString() calls, since they're made even when getFormattedMessage() is never called. Note that I don't control the source of the objects with expensive toString() methods, nor do I control the source everywhere they're logged, so I can't simply change them directly. formattedMessage is already evaluated lazily in getFormattedMessage(), so the only side effect of this change is the introspection of argsArray to look for a Throwable at the end, which is a trivial operation to perform separately.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
participants (3)
-
Andrew Brett (JIRA) -
Joern Huxhorn (JIRA)
-
Richard Wheeldon (JIRA)