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

["Stefan Egli (JIRA)" <ji...@apache.org>]

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

Stefan Egli closed SLING-5256.
------------------------------

> 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
>             Fix For: Discovery Commons 1.0.4, Discovery Base 1.1.0, Discovery Oak 1.1.0
>
>
> 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)