All Known Implementing Classes:

ClusterSyncServiceChain, OakBacklogClusterSyncService, SyncTokenService
```
public interface ClusterSyncService
```
The ClusterSyncService can be used to establish strong consistency with the underlying (eventually consistent) repository in use.
The issue is described in length in SLING-4627 - the short version is composed of two different factors:
- concurrency of discovery service and its listeners on the different instances: upon a change in the topology it is important that one listener doesn't do activity based on an older incarnation of the topologyView than another listener on another instance. they should change from one view to the next view based on the same repository state.
- when an instance leaves the cluster (eg crashes), then depending on the repository it might have left a backlog around which would yet have to be processed and which could contain relevant topology-dependent data that should be waited for to settle before the topology-dependent activity can continue
Both of these two aspects are handled by this ClusterSyncService. The former one by introducing a 'sync token' that gets written to the repository and on receiving it by the peers they know that the writing instance is aware of the ongoing change, that the writing instance has sent out TOPOLOGY_CHANGING and that the receiving instance has seen all changes that the writing instance did prior to sending a TOPOLOGY_CHANGING. The latter aspect is achieved by making use of the underlying repository: eg on Oak the 'discovery lite' descriptor is used to determine if any instance not part of the new view is still being deactivated (eg has backlog). So this second part is repository dependent.

Method Summary

All Methods Instance Methods Abstract Methods
Modifier and Type	Method	Description
`void`	`cancelSync()`
`void`	`sync(BaseTopologyView view, java.lang.Runnable callback)`	Starts the synchronization process and calls the provided callback upon completion.

- Method Detail
  - sync
```
void sync(BaseTopologyView view,
          java.lang.Runnable callback)
```
    Starts the synchronization process and calls the provided callback upon completion.
    sync() is not thread-safe and should not be invoked concurrently.
    If sync() gets called before a previous invocation finished, that previous invocation will be discarded, ie the callback of the previous invocation will no longer be called.
    The synchronization process consists of making sure that the repository has processed any potential backlog of instances that are no longer part of the provided, new view. Plus it writes a 'sync-token' to a well-defined location, with all peers doing the same, and upon seeing all other sync-tokens declares successful completion - at which point it calls the callback.run().
    
    Parameters:
    
    view - the view which all instances in the local cluster should agree on having seen
    
    callback - the runnable which should be called after successful syncing
  - cancelSync
```
void cancelSync()
```

Interface ClusterSyncService

Method Summary

Method Detail

sync

cancelSync