[
https://issues.apache.org/jira/browse/LOG4J2-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986246#comment-13986246
]
Remko Popma commented on LOG4J2-628:
------------------------------------
This is expected behaviour as of RC-1.
The use case for the Clock interface was to allow an extra performance
optimization for users who want to squeeze the last drop of performance out of
the logging subsystem. The trade-off is that the faster CachedClock
implementation shows jumps of 10-16 milliseconds, so you lose accuracy in the
log timestamps.
However this optimization only becomes visible after other bottlenecks have
been removed. The performance bottleneck of Async appender is on the queue, and
optimizing the timestamping mechanism would not make a visible difference in
performance.
If your use case for using a custom Clock is not performance related, can you
clarify what it is you are trying to achieve?
Perhaps it would make sense to use the Clock interface consistently everywhere
in Log4j.
> Cannot set log4j.Clock with Async appender
> ------------------------------------------
>
> Key: LOG4J2-628
> URL: https://issues.apache.org/jira/browse/LOG4J2-628
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
> Affects Versions: 2.0-rc1
> Environment: Ubuntu 12.04 / Java 7
> Reporter: Bryan Hsueh
>
> I override log4j.Clock to support a "live" time vs a "simulated" time.
> System.setProperty("log4j.Clock", "teambh.trade.utils.MyClock");
> If I use asynchronous loggers, it works fine and calls my
> Clock:currentTimeMillis().
> If I switch to async appenders, currentTimeMillis() is not called.
> Is this expected behavior or a bug?
> Thanks
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
