If we used Clock consistently throughout, does this make sense to use everywhere? We use the clock to determine thread killing timeouts for instance. There are other places time is used that if it were to use the Clock interface, we'd have to document the contract required to be followed by it in order to not make everything blow up in a mess of concurrency problems.
On 1 May 2014 14:09, Bryan Hsueh (JIRA) <j...@apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/LOG4J2-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986881#comment-13986881] > > Bryan Hsueh commented on LOG4J2-628: > ------------------------------------ > > Correct, my use case is not performance related. Instead, I implement > Clock so that I can decide whether to use System time or my own artificial, > simulated time. > > I am simulating a program against historical data. So, when I run > historically, I want to see my historical timestamp. When I run live, I > want to see the System timestamp. My Clock:currentTimeMillis() decides > this for me. > > > 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 > > -- Matt Sicker <boa...@gmail.com>
