[
https://issues.apache.org/jira/browse/SLING-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved SLING-5251.
--------------------------------
Resolution: Fixed
rev 1713675:
bq. adding debug infos to the topology webconsole re the SyncTokenService
History
thus considering this done.
> 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)
