On Feb 7, 2013, at 3:01, "Ralph Goers (JIRA)" <j...@apache.org> wrote:
> > [ > https://issues.apache.org/jira/browse/LOG4J2-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573290#comment-13573290 > ] > > Ralph Goers commented on LOG4J2-163: > ------------------------------------ > > I believe the call to checkConfiguration used to be in LoggerConfig but I had > to move it to the Logger to avoid some problems, but I don't recall what they > were now. If you do recall, please add code comments ;) G > > By definition, if a synchronous logger is called from a child thread it is no > longer synchronous and may not behave in the way the application expects. In > a sense, delegation really isn't delegation. If LoggerConfig a.b.c is > asynchronous it can be scheduled and then its parent can immediately be > processed in the same thread that scheduled a.b.c. This has the desirable > effect that if an exception is thrown and suppressExceptions is set to false > then the application will receive the exception. This behavior is impossible > to accomodate if the synchronous LoggerConfig is invoked from an asynchronous > one. > > In other words - what you are expressing would result in a configuration that > behaves like: > > <asynchLogger name="a.b.c" level="debug"> > <appender-ref ref="appender1"/> > <logger name="a.b" level="debug"> > <appender-ref ref="appender2"/> > </logger> > </asynchLogger> > > even though what they actually configured was: > > <asynchLogger name="a.b.c" level="debug"> > <appender-ref ref="appender1"/> > <asynchLogger> > > <logger name="a.b" level="debug"> > <appender-ref ref="appender2"/> > </logger> > > >> Create asynchronous Logger for low-latency logging >> -------------------------------------------------- >> >> Key: LOG4J2-163 >> URL: https://issues.apache.org/jira/browse/LOG4J2-163 >> Project: Log4j 2 >> Issue Type: Improvement >> Affects Versions: 2.0-beta4 >> Reporter: Remko Popma >> Attachments: FastLog4j-v2-for-beta4.zip, FastLog4j-v3-for-beta4.zip >> >> >> One of the main considerations for selecting a logging library is >> performance, specifically, how long it takes for a call to Logger.log to >> return. (See the comments of LOG4J-151 for a discussion of latency versus >> application throughput and logging throughput.) >> I believe it is possible to improve this performance by an order of >> magnitude by having an asynchronous Logger implementation that hands off the >> work to a separate thread as early as possible. The disk I/O would be done >> in this separate thread. >> AsynchAppender is not a good match for these requirements, as with that >> approach (a) the logging call still needs to flow down the hierarchy to the >> appender, doing synchronization and creating objects at various points on >> the way, and (b) when serializing the LogEvent, the getSource() method is >> always called, which is expensive. > > -- > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
