Stefan Egli created SLING-5251:
----------------------------------
Summary: 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. Namely the following:
* 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)
