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
