Thanks so much for confirming the fix and more importantly, sparing time to
share the issue with us. 2.15.0 is supposed to be released soon. We are
waiting for some changes from another maintainer (I am looking at you
Ralph) and then we will be done.
What I would really appreciate is some details about your use case. How do
you purpose JTL? What do you use for the log storage engine? ELK? Which
appender (pipeline?) do you use to make your way from the application to
your long sink? What is the scale? Do you have any Log4j/JTL customizations?
And... Thanks for your kind words. Flu has shackled me to bed for a couple
of days, but I am feeling better now.
On Thu, Oct 28, 2021 at 8:28 PM Andrew Harris (andharr2) <
andrew.har...@appdynamics.com> wrote:
> Volkan,
>
> I am happy to report that the change in
> 2dd7063fb6c6fe73070aded6607a2e2d53613b46 appears to have resolved the
> issue! After building and installing a local snapshot of
> log4j-layout-template-json from release-2.x, I now see the following in my
> test application:
>
> ```
> {"timestamp.epoch":1635443515353213000,"timestamp.iso8601":"2021-10-28T17:51:55.353Z","severityText":"INFO","body":"Starting
> count"}
> {"timestamp.epoch":1635443515360647000,"timestamp.iso8601":"2021-10-28T17:51:55.360Z","severityText":"INFO","body":"Event
> 0"}
> {"timestamp.epoch":1635443516365136000,"timestamp.iso8601":"2021-10-28T17:51:56.365Z","severityText":"INFO","body":"Event
> 1"}
> {"timestamp.epoch":1635443517365604000,"timestamp.iso8601":"2021-10-28T17:51:57.365Z","severityText":"INFO","body":"Event
> 2"}
> ```
>
> After several more runs, including runs over SLF4J, the epoch timestamp
> resolver operates as expected. I am also happy to report that a pattern
> layout also continues to operate as expected.
>
> Speaking to the test added in 2dd7063f, I ran exactly that test against
> the previous head b6774209, and indeed the test fails. Also a good sign,
> the test seems to cover the logging behavior! Seen as follows:
>
> ```
> [ERROR] Failures:
> [ERROR]
>
> TimestampResolverTest.epoch_nanos_should_not_overlap:43->lambda$epoch_nanos_should_not_overlap$1:69
> Found duplicate(s):
> [1635444597296722000L]
> in:
> [1635444597296722000L,
> 1635444597296722000L,
> 1635444597296722000L,
> 1635444597296722000L,
> 1635444597296722000L]
> ```
>
> Meanwhile, of course, the test passes in 2dd7063f.
>
> Thank you for your help here. I am sorry that I wasn't able to isolate the
> issue more quickly, let alone provide a test case myself. Looking forward
> to this change arriving in a future release. Hope you are feeling better,
> too!
>
> Andrew
>
