[
https://issues.apache.org/jira/browse/SLING-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-5251:
-------------------------------
Description:
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_.
was:
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_.
> 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)
