[
https://issues.apache.org/jira/browse/SLING-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160063#comment-14160063
]
Tommaso Teofili commented on SLING-3993:
----------------------------------------
bq. how does OAK support userData
see http://markmail.org/message/i2qy6ck22muwe4oc
> 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)
