Also, seeing that other threaded applications had similar problems, I doubt this is a java issue - more likely a pthread, glibc or even kernel issue
Apparently the issues might be due "to the leapsecond being added without calling clock_was_set() to notify the hrtimer subsystem of the change", a possible fix being to patch kernel/time/timekeeping.c to be leapsecond aware.
This explains it for me. Thanks a lot for the pointer.
Did the link title change from a Java title, like the article, to a Linux title to match the actual root cause?
Yes, it did.
I wonder if this was caused by another VM on the same physical box being hit by the bug and as a result stole CPU time from our VM.
I resolved the issue by moving to a different VM (Rebooting didn't help), to get away from my greedy neighbor.
More info here: http://blog.thinrhino.net.in/cpu-steal-time
My rig crashed all weekend because of this POS bug, I had to boot back to Windows to get anything done (oh cmd, I really didn't miss you at all you insufferable bitch...)
I.e. gradually slow/accelerate time over the course of a day, rather than stepping it hard at once.
I'd say this approach would be vastly preferable for about 100% of the systems relying on pool.ntp.org.
The remaining 0%, e.g. scientific applications that absolutely need the leap second to appear at exactly the right moment, most likely don't use pool.ntp.org anyways.
And for those who do they could create a second pool with the old behavior. Maybe call it science.ntp.org.
When you look at how much people crap their pants over the leap second - a relatively common thing - I dread to think how unprepared people would be for something 3,600 times less common.