Does AMPS correctly handle leap seconds?
AMPS handles leap seconds and abrupt changes to the system time correctly. We've hardened AMPS against things more severe than leap seconds (think: suspending a VM and awakening it hours later).
If you've looked at the timestamps when dumping a journal or SOW file, you'd see 64-bit timestamps that look like the following 212350032000000000. AMPS handles "leaps" just as it handles regular time marching forward. The real protection is provided by a couple of key concepts in AMPS:
Never allow time to go "backwards". We strictly enforce a monotonically increasing timeline. This means if you set time back an hour, all transactions for the next hour will share the same timestamp.
Never assume OS events occur when they're scheduled. There are a few key OS functions that we use to schedule events to wake up threads periodically, but we never assume these are accurate. They can always be triggered early by an OS signal or triggered late due to system load.
We use the same method of "inserting" leap seconds that most other vendors/software choose: mapping the leap second to the next time slot. For example, here are the few timestamps AMPS will be using for the time periods surrounding the next leap second. Notice that 23:59:60 is treated the same as 00:00:00.
That said, there have been issues in the past where the Linux OS has issues with waking timed semaphores or 'futexes' during leap seconds. If you're using RHEL 6.5 or higher you should be safe from all known issues. If you were unlucky and hit an issue, then the worst case scenario would be a restart of your host to recover from the timing related issues during the leap second.
Last updated