[
https://issues.apache.org/jira/browse/SLING-10077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated SLING-10077:
-----------------------------------
Description:
Currently the {{o/a/s/d/a/p/queued}} and {{o/a/s/d/a/p/distributed}} events are
raised as local events in each author instance of a cluster. Handling those
events in each author instance makes sense for use cases that require
maintaining a distributed data structure like a cache. However, some use cases
like content invalidation, would need to handle the events only once.
Currently, event handlers can support the later category of use cases by
deduplicating the events using the Apache Discovery API. This works but it adds
complexity in the event handlers and in some edge case, some events may be lost.
To solve both use cases better, we should move from raising local events in
each author instance to raising the events only on the author leader instance
and [distribute the
events|https://sling.apache.org/documentation/bundles/apache-sling-eventing-and-job-handling.html#distributed-events]
across the cluster. Use cases that need to de-duplicate will be able to do
that by filtering the events with
{code}
if (org.apache.sling.event.EventUtil.isLocal(event)) {
// Process the event on the instance that sent it and thus once per
cluster
}
{code}
The PackageDistributedNotifier would be run only on the cluster leader
instance. The leader instance can be detected using the [Discovery
API|https://sling.apache.org/documentation/bundles/discovery-api-and-impl.html#topology-changes].
We'd need to introduce a new component that listen to topology change and in
case it runs on the leader, register the PackageDistributedNotifier service
using
{code}
org.osgi.framework.BundleContext.registerService(PackageDistributedNotifier.class.getName(),
packageDistributedNotifier, props)
{code}
was:
Currently the `o/a/s/d/a/p/queued` and `o/a/s/d/a/p/distributed` events are
raised as local events in each instance of a cluster. Raising the events in the
cluster make sense for use cases that require maintaining a distributed data
structure like a cache.
Some use case trigger logic on the cluster (not individual instances) and would
benefit from raising a single event.
As an improvement, we could add a mode to distribute or not distribute all
journal distribution events. Distribution would be enabled by default.
> Mode to raise events only locally
> ---------------------------------
>
> Key: SLING-10077
> URL: https://issues.apache.org/jira/browse/SLING-10077
> Project: Sling
> Issue Type: Improvement
> Affects Versions: Content Distribution Journal Core 0.1.18
> Reporter: Timothee Maret
> Assignee: Timothee Maret
> Priority: Major
>
> Currently the {{o/a/s/d/a/p/queued}} and {{o/a/s/d/a/p/distributed}} events
> are raised as local events in each author instance of a cluster. Handling
> those events in each author instance makes sense for use cases that require
> maintaining a distributed data structure like a cache. However, some use
> cases like content invalidation, would need to handle the events only once.
> Currently, event handlers can support the later category of use cases by
> deduplicating the events using the Apache Discovery API. This works but it
> adds complexity in the event handlers and in some edge case, some events may
> be lost.
> To solve both use cases better, we should move from raising local events in
> each author instance to raising the events only on the author leader instance
> and [distribute the
> events|https://sling.apache.org/documentation/bundles/apache-sling-eventing-and-job-handling.html#distributed-events]
> across the cluster. Use cases that need to de-duplicate will be able to do
> that by filtering the events with
> {code}
> if (org.apache.sling.event.EventUtil.isLocal(event)) {
> // Process the event on the instance that sent it and thus once per
> cluster
> }
> {code}
> The PackageDistributedNotifier would be run only on the cluster leader
> instance. The leader instance can be detected using the [Discovery
> API|https://sling.apache.org/documentation/bundles/discovery-api-and-impl.html#topology-changes].
> We'd need to introduce a new component that listen to topology change and in
> case it runs on the leader, register the PackageDistributedNotifier service
> using
> {code}
> org.osgi.framework.BundleContext.registerService(PackageDistributedNotifier.class.getName(),
> packageDistributedNotifier, props)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
