You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Jean-Daniel Cryans (JIRA)" <ji...@apache.org> on 2017/12/04 22:58:00 UTC

[jira] [Updated] (KUDU-2209) HybridClock doesn't handle changes STA_NANO status flag

     [ https://issues.apache.org/jira/browse/KUDU-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Daniel Cryans updated KUDU-2209:
-------------------------------------
       Resolution: Fixed
    Fix Version/s: 1.5.1
                   1.6.0
                   1.4.1
                   1.2.1
                   1.3.2
           Status: Resolved  (was: In Review)

Thanks Attila, I pushed your cherry-pick and it's now everywhere.

> HybridClock doesn't handle changes STA_NANO status flag
> -------------------------------------------------------
>
>                 Key: KUDU-2209
>                 URL: https://issues.apache.org/jira/browse/KUDU-2209
>             Project: Kudu
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 1.6.0
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>            Priority: Critical
>             Fix For: 1.3.2, 1.2.1, 1.4.1, 1.6.0, 1.5.1
>
>
> Users have occasionally reported spurious crashes due to Kudu thinking that another node has a time stamp from the future. After some debugging I realized that the issue is that we currently capture the flag 'STA_NANO' from the kernel only at startup. This flag indicates whether the kernel's sub-second timestamp is in nanoseconds or microseconds. We initially assumed this was a static property of the kernel. However it turns out that this flag can get toggled at runtime by ntp in certain circumstances. Given this, it was possible for us to interpret a number of nanoseconds as if it were microseconds, resulting in a timestamp up to 1000 seconds in the future.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)