[
https://issues.apache.org/jira/browse/SLING-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14156472#comment-14156472
]
Tommaso Teofili commented on SLING-3993:
----------------------------------------
bq. 1. identifying the source of the event that generates the replication so
that events on changed resources generated by the package builder (upon package
installation) are filtered and do not trigger a replication request.
while there's no currently fully working solution based on this approach, the
following options may be explored:
1. enhance the Sling event support to possibly add a 'source' metadata to the
event, in that manner the package builder would specify itself as the 'event
source' and the trigger would filter events generated by that source
2. let the VLT based package builder define ObservationManager's userData for
its session so that the trigger can filter events with specific userData, that
would need either to use a JCR Event based trigger or to keep using Sling event
once SLING-3983 is fixed (and bundle released). The advantage of both these
approaches is that it should be relatively easy to implement while the
disadvantage is that it would only work with JCR (this is not IMHO a problem
per se for replication, as it currently already depends on JCR). On a separate
note I've heard that there're some limitations in the way Oak supports such
userData, maybe it'd be good to clarify that before moving forward on this path
> Avoiding loops when syncing via coordinate agents
> -------------------------------------------------
>
> Key: SLING-3993
> URL: https://issues.apache.org/jira/browse/SLING-3993
> Project: Sling
> Issue Type: Bug
> Components: Replication
> Reporter: Tommaso Teofili
> Assignee: Tommaso Teofili
>
> In the case of a 'coordinate agent', sitting on 'author' instance,
> responsible for synchronizing 2+ 'publish' instances the simplest setup would
> consist of a 'queueing agent' (local exporter, no importer) sitting on each
> of the 'publish' instances with a trigger responsible of signaling changes of
> resources under a certain path so that when, for example, a resource 'bar'
> gets created under '/foo' the trigger will cause the creation of a package
> for '/foo/bar' which will be queued locally, the 'coordinate agent' will
> remotely fetch such a package from the queue of e.g. 'pub1' instance and
> remotely import it into 'pub2' instance.
> If both 'pub1' and 'pub2' have the same trigger this may result into a
> looping scenario when instances keep exchanging packages for the same changed
> content.
> Possible solutions to this can be, conceptually, based on:
> 1. identifying the source of the event that generates the replication so that
> events on changed resources generated by the package builder (upon package
> installation) are filtered and do not trigger a replication request.
> 2. filtering packages before they get transported if a same/similar package
> has been already sent by the target instance, keeping something a cache-like
> structure for the communication (in the coordinate agent).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
