Sure, I'll try find some time this week to try it out. Cheers, Al.
Sent: Saturday, February 10, 2018 at 8:11 PM From: "Remko Popma" <remko.po...@gmail.com> To: "Log4J Users List" <log4j-user@logging.apache.org> Subject: Re: Best approach for sub-millisecond timestamps? > Alfred, > > Sub-milli time stamps have been implemented and will be in the next > release. Note that this uses standard Java APIs and will only work on > Java 9 and higher. The next release is feature complete and will come > out as soon as the release manager has time to do the work. > > As Gary pointed out, you can try this now with a SNAPSHOT release. I > couldn't find a link to the SNAPSHOT releases on the site, but the > README in git has a link: > https://logging.apache.org/log4j/2.x/maven-artifacts.html#Snapshot_builds > > We should add this link to the main site. > > (Shameless plug) Every java main() method deserves > http://picocli.info > > > On Feb 11, 2018, at 6:22, Gary Gregory <garydgreg...@gmail.com> wrote: > > > > Why not give a SNAPSHOT build a go? > > > > Gary > > > >> On Feb 10, 2018 14:14, <alfred.eckm...@gmx.com> wrote: > >> > >> Thank you for the pointer, Ralph. Glad to see there's good progress on > >> this. > >> > >> In the meantime I guess I'll have to stick with my current approach, > >> except I'll change it to (ab)use NanoClock/nanoTime field instead. > >> > >> Cheers, > >> Al. > >> > >> Sent: Saturday, February 10, 2018 at 2:16 PM > >> From: "Ralph Goers" <ralph.go...@dslextreme.com> > >> To: "Log4J Users List" <log4j-user@logging.apache.org> > >> Subject: Re: Best approach for sub-millisecond timestamps? > >> > >>> See https://issues.apache.org/jira/browse/LOG4J2-1883 > >>> <https://issues.apache.org/jira/browse/LOG4J2-1883> > >>> > >>> Ralph > >>> > >>>> On Feb 10, 2018, at 10:42 AM, alfred.eckm...@gmx.com wrote: > >>>> > >>>> Hello list, > >>>> > >>>> I need to get more granular timestamps in my logs. > >>>> > >>>> The question is what is the best way get Log4j to handle > >>>> sub-millisecond timestamps? > >>>> > >>>> A top search result provides this deceptively-simple approach: > >>>> http://blog.caplin.com/2017/10/13/microsecond-time-stamp- > >> logging-for-mifid-ii/ > >>>> > >>>> However, that will provide wrong results, since they're generating the > >>>> timestamp inside the Converter, which would run in the AsyncLogger > >>>> thread and in effect log when the event was processed rather than when > >>>> it actually occurred. > >>>> > >>>> The hack I came up with is to implement a custom Clock whose > >>>> currentTimeMillis() returns nanoseconds since the epoch, and a > >>>> corresponding Converter plugin that handles nanoseconds in the > >>>> millisecond field (Hopefully it won't still be around by year 2262 :) > >>>> It works pretty well for what I'm doing so long as both the custom > >>>> clock and a correct layout are used, but I imagine it could cause > >>>> unexpected consequences if some time-related functionality is used > >>>> (e.g. file rolling). > >>>> > >>>> Any suggestions for a cleaner but low-overhead approach? > >>>> > >>>> Cheers, Al. > >>>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > >> For additional commands, e-mail: log4j-user-h...@logging.apache.org > >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
