Klaus Grønbæk

Cool, let me build a small project to illustrate

I'm unable to reproduce this in a simple stand alone project. When I debug it I can see some differences in the call stack depth at the point where the...

I figure out how to reproduce this, it seems to happen when the test has a real Web server environment `@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)` I started with JUnit 4 and boot...

Since you are only using UTC and will probably discard the leap second (as you can't store it in `java.time`), you could take a simple contains-replace approach: ``` if (str.contains("59:60"))...

You could use Date via SimpleDateFormat, but it has some caveats, look at this code ``` SimpleDateFormat format = new SimpleDateFormat("yyyyMMdd-HH:mm:ss"); format.setTimeZone(TimeZone.getTimeZone("UTC")); Instant instant = format.parse("19981231-23:59:60").toInstant(); System.out.println("instant = " +...

I must agree with @nolag, it looks suspect, and I think there is a bug. The locks are there to prevent concurrent modification. This applies to the increment of sequence...

I have change my mind, I don't think there is a bug. There was a change to the memory model back in Java 5. Synchronization actions, like volatile read/write, lock/unlock...

hehe, I have changed my mind again ;) I believe you are correct. When the sender thread acquires the `senderMsgSeqNumLock` we have what the Java spec calls a _Synchronization action_,...