[
https://issues.apache.org/jira/browse/SLING-10077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494457#comment-17494457
]
Timothee Maret commented on SLING-10077:
----------------------------------------
Thanks [~joerghoh]. Interestingly I was just double checking the implementation
of the distributed events and figured it's creating resources in the
repository. That's completely against the design goals we have for journal
based content distribution. Currently the author tier repository is only used
for exporting content and we should keep it that way.
Yes, it's possible to keep the existing approach. We would introduce a mode
that only raise the event on the leader repository. In a nutshell, we'd do what
users would do to de-duplicate events.
> 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)
