[ 
https://issues.apache.org/jira/browse/LOG4J2-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575372#comment-13575372
 ] 

Remko Popma commented on LOG4J2-153:
------------------------------------

While working on AsyncLoggerConfig for LOG4J2-163, I was confronted with this 
issue again.
Async loggers cannot lazily take a stack snapshot, they need to decide before 
handing off to the other thread...

Latency of a call to Logger.log:
root + %location pattern: ~40 microsec
root without %location:  ~5.4 microsec
asyncRoot (with stack snapshot): ~15 microsec <--- ouch!
asyncRoot (no stack snapshot) :  0.6 microsec

I see 4 options:
1. Always include location info.
   AsyncLoggerConfig would be 3x times slower than sync logger if no appender 
needs location, making it useless for users who don't want location info.

2. Never include location info.
   But some users do want location info... Maybe not a real option either.

3. Automatically detect if location is required.
   This seems difficult and requires many API and impl changes in many places

4. Manually specify if location is required.
   This may be our most practical solution, even if not very elegant.


I propose to add a "needsLocation" attibute to the logger and asyncLogger 
config. (Better name, anyone? "skip/omitLocation"? "location"?)
The default would be to include location information.

The only drawback I see is some added complexity around additivity with parent 
loggers having different needsLocation settings.

Example config snippet:
  <loggers>
    <asyncLogger name="com.foo.Bar" level="trace" needsLocation="false">
      <appender-ref ref="File"/>
    </asyncLogger>
    <root level="info">  <!-- needsLocation not specified, so "true" by default 
--> 
      <appender-ref ref="File"/>
    </root>
  </loggers>

Thoughts?
                
> Async Logger/Appender performance improvement: provide mechanism to discover 
> if location StackTraceElement is actually required downstream.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-153
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-153
>             Project: Log4j 2
>          Issue Type: Improvement
>            Reporter: Remko Popma
>
> (update 2013 Feb 4: changed summary.
> Previous title: Add a method to the Layout interface to allow Loggers to 
> discover if any of their Appenders need the location StackTraceElement.)
> ----
> Use Case: any asynchronous Logger or Appender has this problem:
> should it take a snapshot of the call stack (as implemented in 
> Log4jLogEvent.getSource) or not?
> This is an expensive method (1600+ nanoseconds on a machine with 2.9GHz 
> cores) so you only want to call it if you need it. Currently there is no way 
> to discover if the location information is used by any of the configured 
> layouts.
> If the Layout interface has a method that indicates whether the layout calls 
> the LogEvent.getSource method, then the Logger can query its LoggerConfig if 
> any of the configured Appenders has a Layout which needs location info. 
> (Maybe boolean needsLocationInfo() would be a good name?)
> With this information, a Logger can construct Log4jLogEvents with a non-null 
> dummy StackTraceElement location if none of the layouts downstream need 
> location info. The non-null dummy location would prevent LogEvent.getSource 
> from taking a call stack snapshot.
> The current AsynchAppender class would get an immediate performance boost 
> from this, and custom asynchronous Loggers or Appenders would reap the same 
> benefits.

--
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

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to