[
https://issues.apache.org/jira/browse/SLING-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated SLING-3993:
-----------------------------------
Description:
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).
was:
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.
> 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)
