AEM 6.3: Author -> dispatcher flush also executes replication event to publishers | Community
Skip to main content
J
JeroenDruwe
Level 4
January 16, 2019

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

  • January 16, 2019
  • 2 replies
  • 9726 views

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...

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

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

2 replies

Gaurav-Behl
Gaurav-Behl
Level 10
January 16, 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?

    J
    JeroenDruweAuthor
    Level 4
    January 17, 2019

    This is our triggers tab:
    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?

      joerghoh
      Adobe Employee
      joerghohAdobe Employee
      Adobe Employee
      January 16, 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

        J
        JeroenDruweAuthor
        Level 4
        January 17, 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.

          J
          JeroenDruweAuthor
          Level 4
          January 22, 2019

          I'm able to reproduce the behavior you mentioned only if I turn on "On modification" checkbox of either publish agent or flush/invalidation agent and this makes sense because 'pushonmodify' would trigger 'onModify' event which these agents would capture and trigger the replication & flush accordingly.

          If 'on modification' is left unchecked on both publish agent and invalidation agent, I do not see any publish activity with either of 'pushonmodify' or 'activate' rollouts unless the author publishes the content manually. Even after removing 'pushonmodify' and doing a manual rollout doesn't trigger publish activity.

          couple of questions/tasks:

          • How have you configured the flush agent to be triggered automatically on modification as you have mentioned in the description? Is it via "On modification" checkbox under "Triggers" tab or something else?
          • Do you have "On modification" checkbox turned on under "Triggers" tab for default publish agent?
          • Could you disable both default publish agent and dispatcher flush agent and check the blocked queues for both agents - http://localhost:4502/etc/replication/agents.author/flush.html  and http://localhost:4502/etc/replication/agents.author/publish.html
            • Validate the user name that triggers the replication and flush? Is it 'msm-service' or 'replication-service' or some other?
            • Validate the sequence of tasks for flush and replication. If pushonmodify rollout/msm triggers that replication, then you should see the user name as 'msm-service'. If its triggered by flush agent, then it would be with user 'replication-service'
          • Just to be clear - If you remove/disable the flush/invalidation agent then you do not observe this kind of auto-replication behavior? You could validate same with above mentioned step of checking publish agent queue/logs.
          • Could you remove 'pushonmodify' from live copies and do a manual rollout from source page and check the behavior if automated publish still happens?

          reference - MSM Best Practices,

          onModify

          When using the rollout trigger onModify you should consider that:

          • Automating rollouts with onModify triggers may have a negative impact on authoring performance as they trigger rollouts after every page modification.
          • The rollout result may differ from the one expected as:
            • You cannot specify the order of the resulting modify events.
            • The event-based architecture cannot guarantee the sequence of the events passed to the Rollout Manager.
          • Using such a rollout configuration could lead to commit conflicts if concurrent updates of the same resource occur.

          Therefore, it is recommended that you only use onModify triggers if the benefits of automatic rollout initiation outweigh any potential performance issues.


          How have you configured the flush agent to be triggered automatically on modification as you have mentioned in the description? Is it via "On modification" checkbox under "Triggers" tab or something else?

          The dispatcher flush agent is the only agent that has the trigger 'On Modification' checked on its triggers tab.

          Do you have "On modification" checkbox turned on under "Triggers" tab for default publish agent?

          The publish agent has no triggers checked on its triggers tab.

          Could you disable both default publish agent and dispatcher flush agent and check the blocked queues for both agents http://localhost:4502/etc/replication/agents.author/flush.html  and http://localhost:4502/etc/replication/agents.author/publish.html

          • Validate the user name that triggers the replication and flush? Is it 'msm-service' or 'replication-service' or some other?
            • NOTE: I have not disabled the agents but just changed their target ip's because disabling resulted in seeing no queued items at all for both of them.
            • Editing a component
              • Dispatcher flush agent

              • Publish agent

            • Publishing the page
              • Dispatcher flush agent
              • Publish agent
          • Validate the sequence of tasks for flush and replication. If pushonmodify rollout/msm triggers that replication, then you should see the user name as 'msm-service'. If its triggered by flush agent, then it would be with user 'replication-service'
            • See answer above, both 'msm-service' and 'replication-service' are listed.

          Just to be clear - If you remove/disable the flush/invalidation agent then you do not observe this kind of auto-replication behavior? You could validate same with above mentioned step of checking publish agent queue/logs.

            • Editing a component
              • Dispatcher flush agent
                • No items on queue due to the agent being disabled
              • Publish agent
                • NO item is being added to the queue
            • Publishing a page
              • Dispatcher flush agent
                • No items on queue due to the agent being disabled
              • Publish agent

          It seems that when the dispatcher flush agent is disabled I indeed don't see the auto-replication behaviour on modification only when I actually publish the page the corresponding item will be added to the publish agent queue.

          Could you remove 'pushonmodify' from live copies and do a manual rollout from source page and check the behavior if automated publish still happens?

          When I replace my LiveCopy rollout configuration:

          /etc/msm/rolloutconfigs/activate

          /etc/msm/rolloutconfigs/deactivate

          /etc/msm/rolloutconfigs/pushonmodify

          BY:

          /etc/msm/rolloutconfigs/activate

          /etc/msm/rolloutconfigs/deactivate

          /etc/msm/rolloutconfigs/default

          And trigger a manual rollout using http://localhost:4502/etc/blueprints.html , the auto-replication behaviour is NOT happening anymore. We benefit a lot from the '/etc/msm/rolloutconfigs/pushonmodify' config, we are aware of the potential negative performance impact.

            Terms & ConditionsAccessibility statement

            Loading footer...