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/11/04 10:12:27 UTC

[jira] [Created] (SLING-5256) change in localClusterSyncTokenId should always trigger a TOPOLOGY_CHANGED

Stefan Egli created SLING-5256:
----------------------------------

             Summary: change in localClusterSyncTokenId should always trigger a TOPOLOGY_CHANGED
                 Key: SLING-5256
                 URL: https://issues.apache.org/jira/browse/SLING-5256
             Project: Sling
          Issue Type: Bug
          Components: Extensions
    Affects Versions: Discovery Oak 1.0.2, Discovery Base 1.0.2, Discovery Commons 1.0.2
            Reporter: Stefan Egli
            Assignee: Stefan Egli
            Priority: Minor


Normally when a topology changes this is either because an instance joined or left (or because properties change, but that's another topic). And whenever an instance joins or leaves this is triggering a TOPOLOGY_CHANGED as expected.

However there could be the unlikely scenario that from a state (a) an instance joins creating state (b), then leaves relatively quickly again resulting in state (c) - and one other instance in the cluster happens to be so busy that it 'misses' the intermediate state (b) - which means it will compare state (a) with state (c) which it could see as being equal since, well, that it almost is. 

But to be correct, the above comparison between (a) and (c) should still trigger a TOPOLOGY_CHANGED event. And that is already possible since (a) and (c) have a differing {{localClusterSyncTokenId}} (by definition).

Long story short: the code should treat two TopologyViews with differing {{localClusterSyncTokenId}} as different (thus automatically causing a TOPOLOGY_CHANGED as a result)



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