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

Reply via email to