You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Stefan Egli (JIRA)" <ji...@apache.org> on 2015/01/29 18:13:34 UTC

[jira] [Resolved] (SLING-3434) Make intra-cluster discovery-heartbeats independent from machine clock differences

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

Stefan Egli resolved SLING-3434.
--------------------------------
    Resolution: Incomplete
      Assignee: Stefan Egli

Marking this issue resolved/incomplete as the suggestion is to not reinvent NTP but rather come up with a simple health-check based on the newly added 'votedAt' property. The health-check ticket is SLING-4371, thus nothing left to do here.

> Make intra-cluster discovery-heartbeats independent from machine clock differences
> ----------------------------------------------------------------------------------
>
>                 Key: SLING-3434
>                 URL: https://issues.apache.org/jira/browse/SLING-3434
>             Project: Sling
>          Issue Type: Bug
>          Components: Extensions
>    Affects Versions: Discovery Impl 1.0.2
>            Reporter: Stefan Egli
>            Assignee: Stefan Egli
>             Fix For: Discovery Impl 1.0.14
>
>
> SLING-2967 fixed an issue where topology connectors were dependent on having machine clocks in sync - so inter-cluster we're no longer dependent on NTP-synching.
> Inside a cluster though, this problem is still there. Since heartbeats are written as absolute time - based on the originator's machine clock - it still only works fine the whole cluster is NTP-synched.
> In general I think this is not a problem as it is best-practice to make sure machines have NTP set up.
> Nevertheless, it would help if discovery.impl could become independent from this.
> Also, if clocks are off by too much, pseudo-network-partitions can occur, with the result of having multiple leaders in a cluster (also see SLING-3432)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)