Highlighted

AEM 6.3: Author -> dispatcher flush also executes replication event to publishers

Avatar

Avatar

Jdruwe

Avatar

Jdruwe

Jdruwe

16-01-2019

Let me first describe our 2 agents on our author environment:

- Dispatcher flush agent (we have a dispatcher in front of our author environment to add an extra layer of caching for the content authors)

- Default agent (used for publishing to the publish environment)

NOTE: obviously 2 different entities.

The dispatcher flush agent is new in our setup and gets trigger on modification. After adding the agent our content author complained that their changes were automatically published for some reason. After some investigation/debugging of the com.day.cq.replication.impl.ReplicatorImpl it seems that there is also a replication event fired by the RolloutManager with the following ReplicationOptions (note: no AgentIdFilter or ReplicateOnModification filter)

ReplicationOptions{synchronous=false, revision='null', suppressStatusUpdate=false, suppressVersions=false, filter=null, aggregateHandler=null}

No filter results in all enabled agents to be triggered so the path will get replicated to the publishers, NOT wat we want...

1669544_pastedImage_0.png

It seems to me the the combination of a dispatcher flush agent and default agent is not working properly. Anyone experiencing the same problems?

Replies

Highlighted

Avatar

Avatar

Gaurav-Behl

MVP

Total Posts

1.1K

Likes

226

Correct Answer

281

Avatar

Gaurav-Behl

MVP

Total Posts

1.1K

Likes

226

Correct Answer

281
Gaurav-Behl
MVP

16-01-2019

Since the flush agent is on author, could you validate that the "Triggers" tab of the flush agent doesn't have any checkbox turned on esp. Ignore Default or On Modification?

Are you doing programmatic replication/flushing or any workflow based replication/flushing of the content using ReplicationOptions?

Highlighted

Avatar

Avatar

Jörg_Hoh

Employee

Total Posts

3.0K

Likes

910

Correct Answer

1.0K

Avatar

Jörg_Hoh

Employee

Total Posts

3.0K

Likes

910

Correct Answer

1.0K
Jörg_Hoh
Employee

16-01-2019

In any case, the RolloutManager would always fire a replication event if it's configured in that way; it does not depend on the fact if a flush agent is configured or not (or even a combination of standard replication agent and flush agent).

I assume that it's just a coincidence of these 2 activities, and that the flush agent has nothing to do with it. Have you changed your rollout configuration recently to include replication?

Jörg

Highlighted

Avatar

Avatar

Jdruwe

Avatar

Jdruwe

Jdruwe

16-01-2019

This is our triggers tab:1670072_pastedImage_0.png
And no workflows are doing such a thing in our codebase at the moment. Wouldn't I see our custom class if we had one when debugging?

Highlighted

Avatar

Avatar

Jdruwe

Avatar

Jdruwe

Jdruwe

16-01-2019

I am testing it on a local machine with a default and dispatcher flush agent pointing to our acceptance env. so it would can't be a coincidence because I see it every time and I am the only one testing on my local machine. We have the following rollout configs on our livecopy:

- /etc/msm/rolloutconfigs/pushonmodify
- /etc/msm/rolloutconfigs/activate
- /etc/msm/rolloutconfigs/deactivate

We had the above config from the start of the project and never had any pages publish automatically on edit. We only want the dispatcher flush on edit for now.

Highlighted

Avatar

Avatar

Jörg_Hoh

Employee

Total Posts

3.0K

Likes

910

Correct Answer

1.0K

Avatar

Jörg_Hoh

Employee

Total Posts

3.0K

Likes

910

Correct Answer

1.0K
Jörg_Hoh
Employee

18-01-2019

Ah, that's a tough one then. But if you can replicate it, it's getting easier 🙂

So you think that the invalidation agent is also triggering the default replication agent, which is the publishing the changed page?

Highlighted

Avatar

Avatar

Gaurav-Behl

MVP

Total Posts

1.1K

Likes

226

Correct Answer

281

Avatar

Gaurav-Behl

MVP

Total Posts

1.1K

Likes

226

Correct Answer

281
Gaurav-Behl
MVP

18-01-2019

An old thread but this might help-

Replicating and controlling live copy replication

In this use case, the live copy had rollout config 'Activate on blueprint activation'..

Highlighted

Avatar

Avatar

Jdruwe

Avatar

Jdruwe

Jdruwe

18-01-2019

Something like that is happening I think. Not sure how to fix it.

Highlighted

Avatar

Avatar

Jdruwe

Avatar

Jdruwe

Jdruwe

18-01-2019

But isn't '- /etc/msm/rolloutconfigs/activate' rollout config for the LiveCopy a preferred setting, it makes sense in my opinion.

Highlighted

Avatar

Avatar

Jörg_Hoh

Employee

Total Posts

3.0K

Likes

910

Correct Answer

1.0K

Avatar

Jörg_Hoh

Employee

Total Posts

3.0K

Likes

910

Correct Answer

1.0K
Jörg_Hoh
Employee

19-01-2019

How is your "invalidation" agent configured on author? You should have these checkboxes ticked on the "Triggers" tab:

* Ignore default

* On Modification

* No Status Update

* No Versioning

This should prevent a number of unwanted side effects on regular processes (especially "no status update" and "no versioning"). On the other hand, every invalidation request will also trigger an OSGI event about a successful replication event and I don't think that this can be suppressed.

On the other hand side I am not aware of any side effect of such an invalidation agent, it will definitely not trigger any other replication agent.

The problem you face might be caused indirectly by this, does your code react on these OSGI events?

Jörg