org.apache.sling.discovery.commons.providers.spi

Interface ClusterSyncService

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

Modifier and Type	Method and Description
void	cancelSync()
void	sync(BaseTopologyView view, Runnable callback) Starts the synchronization process and calls the provided callback upon completion.

Method Detail

sync

void sync(BaseTopologyView view,
          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()