4

I want to know if the Java build 1.7.0_51-b13 version is vulnerable to leap seconds or not?

I have a cluster of servers running Tomcat. Since July 1 we have a huge CPU usage. We tried to stop ntp and date -s "date" in vain.

The Redhat kernel and tzdata package were patched since June.

useful links:

oussemos
  • 93
  • 1
  • 8
  • 1
    What do you mean by "vulnerable to leap seconds?" The most likely answer is "maybe for a second." Or perhaps you're talking about time accuracy? – Robert Harvey Jul 07 '15 at 14:36
  • vulnerable in this case mean ==> CPU overload usage and system instability – oussemos Jul 07 '15 at 14:38
  • The likelihood that an extra second in a time calculation is going to overload your CPU is pretty much zero. There's an infinitesimally small chance of some sort of crash or exception, but it's so unlikely as to be not worth worrying about. – Robert Harvey Jul 07 '15 at 14:40
  • @RobertHarvey have a look on the links that i've added on my post – oussemos Jul 07 '15 at 14:47
  • Had a similar issue; we have a number of (virtual) Debian servers. Huge CPU usage after the night with the leap second but it looked like it was not because of our Java processes. Rebooted the servers and problem went away. – Jesper Jul 07 '15 at 14:52
  • 1
    @RobertHarvey Software can do strange things when an extra second is added to the clock; it's not so surprising that some pieces of software can't deal with a leap second properly. – Jesper Jul 07 '15 at 14:53
  • 1
    @Jesper: Unfortunately the answer to the question "Is a leap second bug in the Java JDK causing our huge CPU usage issues?" is "We don't know." – Robert Harvey Jul 07 '15 at 14:56
  • @RobertHarvey That's true, we don't know. But your comments seemed to suggest to me that you didn't believe there's any chance that this might cause a problem. – Jesper Jul 08 '15 at 07:05

1 Answers1

1

It's down to the implementation. It's unlikely that your JVM supports leap seconds.

From java.util.Date documentation:

Although the Date class is intended to reflect coordinated universal time (UTC), it may not do so exactly, depending on the host environment of the Java Virtual Machine. Nearly all modern operating systems assume that 1 day = 24 × 60 × 60 = 86400 seconds in all cases. In UTC, however, about once every year or two there is an extra second, called a "leap second." The leap second is always added as the last second of the day, and always on December 31 or June 30. For example, the last minute of the year 1995 was 61 seconds long, thanks to an added leap second. Most computer clocks are not accurate enough to be able to reflect the leap-second distinction.

(Out of interest, and not connected at all with Java, Google NTP servers stretch the seconds in a day that has a leap second, so the extra time is allocated linearly across the seconds in that day.)

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • `Google stretch the seconds in a day that has a leap second, so the extra time is allocated linearly across the seconds in that day` -- Really? I very much doubt that. Every implementation on the planet adds an extra second in the minute just before midnight. – Robert Harvey Jul 07 '15 at 14:38
  • 1
    google smears the leap second in their NTP infrastructure, which doesn't have anything to do with java. – Marc B Jul 07 '15 at 14:38
  • @MarcB Indeed: that was what I was trying to say. – Bathsheba Jul 07 '15 at 14:39
  • That would be damned inconvenient for any application that expects individual seconds to be an accurate time referent. – Robert Harvey Jul 07 '15 at 14:41
  • 1
    Yup. That's life. If you need accurate timings then you're best off writing your own stuff or using a rigid library designed for that purpose. (I worked with such things during my doctorate.) – Bathsheba Jul 07 '15 at 14:42
  • The new java.time framework also defines a Leap Second Smear over the last thousand seconds of the day (same idea as Google's smear but different details). See [my Answer](http://stackoverflow.com/a/30989049/642706) on similar Question for doc excerpts. But this smear is only required where the Java implementation *has* a leap second. No conventional Java implementation I know of recognizes the Leap Second (perhaps a Real-Time Java implementation might). So effectively, all three Java date-time frameworks (java.util.Date/.Calendar, Joda-Time, java.time) ignore Leap Second. – Basil Bourque Jul 07 '15 at 16:47