Re: Best approach for sub-millisecond timestamps?

[Alfred . Eckmann]

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

Re: Best approach for sub-millisecond timestamps?

[Remko Popma]

Oops, for some reason I misread that link. It’s on the site already. Good.

On Sun, Feb 11, 2018 at 10:11 Remko Popma <remko.po...@gmail.com> wrote:

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

Re: Best approach for sub-millisecond timestamps?

[Remko Popma]

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

Re: Best approach for sub-millisecond timestamps?

[Gary Gregory]

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

Re: Best approach for sub-millisecond timestamps?

[Alfred . Eckmann]

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

Re: Best approach for sub-millisecond timestamps?

[Ralph Goers]

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