You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Attila Bukor (JIRA)" <ji...@apache.org> on 2017/11/29 15:54:00 UTC

[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16270981#comment-16270981 ] 

Attila Bukor commented on KUDU-2209:
------------------------------------

[~tlipcon] as I can see this has been merged into all target branches, can we mark this JIRA as resolved?

> 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
>
> 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)