[jira] [Closed] (SLING-5251) discovery.impl should use SyncTokenService (configurable)

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

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

Stefan Egli closed SLING-5251.
------------------------------

> discovery.impl should use SyncTokenService (configurable)
> ---------------------------------------------------------
>
>                 Key: SLING-5251
>                 URL: https://issues.apache.org/jira/browse/SLING-5251
>             Project: Sling
>          Issue Type: Improvement
>          Components: Extensions
>    Affects Versions: Discovery Impl 1.2.0
>            Reporter: Stefan Egli
>            Assignee: Stefan Egli
>             Fix For: Discovery Impl 1.2.2
>
>
> The SyncTokenService introduced with discovery.commons allows discovery implementors to add additional QoS to a TOPOLOGY_CHANGED event by waiting for each instance to store a 'sync token' (eg cluster *view* id, not cluster id) into the repository. The algorithm in detail:
> * upon detecting a topology change happening, each instance sends out TOPOLOGY_CHANGING to its listeners
> * *after* that is done, it stores a syncToken to a well-known place into the repository
> * thus when a particular instance sees all syncTokens by the peers, it knows that all listeners have now gotten the TOPOLOGY_CHANGING event - and that provides a strong synchronization guarantee.
> This mechanism is already in-use by default in discovery.oak (which additionally also ensures no instance has any backlog with the repository - which it can do as it requires oak and oak provides this info in the discovery-lite descriptor).
> Now for discovery.impl such a 'strong cluster synchronization' guarantee is not that relevant as it might look. Since discovery.impl already uses the repository (and thus its delays) for voting and creating the establishedView. But at the moment there is no guarantee that the voting happens *after* the TOPOLOGY_CHANGING was processed by all listeners. It's just rather unlikely that sending the TOPOLOGY_CHANGING (which is all local) is slower than the voting (which is going through repository delays).
> Nevertheless, using the SyncTokenService would provide mentioned strong cluster synchronization guarantee and _discovery.impl could just as well make use of it_.



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