The initial value of this flag is only part of the picture and you should not draw too many conclusions from it.
Log4j2 is very careful about avoiding this overhead. When logging synchronously, log4j2 will postpone taking a snapshot of the call stack until the last possible moment: the moment that a layout requires location information. If a layout does not require location information the call stack snapshot is *never* taken. See the layout documentation ( http://logging.apache.org/log4j/2.x/manual/layouts.html#LocationInformation ) on which patterns require location information. When logging asynchronously, log4j2 needs to make a decision before handing off the log event to the background thread. Only the calling (application) thread has the necessary call stack information; after the log event has been passed to the background thread it cannot be obtained any more. Taking a call stack snapshot is expensive, as you said, so by default log4j will *not* include location information when logging asynchronously. (See AsyncLoggerConfig.java line 204, AsyncAppender.java line 193). If you want location info you need to explicitly configure it with includeLocation=true. Why do you think log4j is taking unnecessary stack trace snapshots? FYI, this is the method that takes a call stack snapshot: Log4jLogEvent.java #calcLocation line 382. Is this where your profiler indicates log4j2 is consuming CPU? On Sun, Nov 30, 2014 at 6:19 PM, Yair Ogen (yaogen) <[email protected]> wrote: > Copied from "LoggerConfig" Source: > > private boolean includeLocation = true; > > so if I don't override this is on, and I indeed this this consuming CPU in > profiling. > > Am I missing something here? >
