-1

i should be able to copy renditions of the asset from the worker instance to master instance and then delete the asset inthe worker instance using the DAM update asset offloading workflow

Arj
  • 1
  • 3
  • Its not clear what you are trying to achieve. By default the offloading workflow delegates to the work to slave/offloading instances and the processed output is reflected back on the leader instance. Do you just want a clean up on the offloading/slave instances? – Ameesh Trikha Jul 21 '16 at 20:30
  • yes, i want the asset in the slave instance to be deleted.I think i might be able to do that by adding the delete dam asset component to my dam update asset workflow in the slave instance. But its not working. Have you done that before? – Arj Jul 22 '16 at 13:29

1 Answers1

0

In my opinion its not a good practice to update the Update Asset workflow on worker instance -

  1. This whole offloading is based on Sling Discovery and eventing mechanism. Which requires offloaded asset to be sent back (read reverse replication) to Leader instance
  2. Adding a step within Update Asset Workflow may cause issues with reverse replication of asset.

You will have to build something independent of the offloading process to achieve this deletion. There are multiple ways to do it -

One possible way -

  • Have JMS based implementation to monitor reverse replication
  • If reverse replication is successful either delete the asset or mark the asset for deletion (highly recommended)
  • If following the approach of marking asset for deletion, setup a cleanup task to run only of worker instance (scheduled to convenient time). This cleanup task identifies the assets marked for deletion and processes them.

IMHO marking asset for deletion is better approach as its more performant and efficient. All assets are processed at once during off-peak time.

There are other ways to this as well but would require a lot of custom code to be written.

Updates -

Tapping into Reverse Replication -

You need to get into the details of the working of reverse replication.

  • Content to be reverse replicated is pushed to OUTBOX
  • If you look at /etc/replication/agents.publish/outbox/jcr:content on your local instance, look for property transportUri which is by default - repo://var/replication/outbox i.e. content to reverse replicated is pushed to '/var/replication/outbox'
  • Now look at /libs/cq/replication/components/revagent/revagent.jsp, This is the logic that works on the receiving instance.

Going through above will give you deeper understanding of how reverse replication is working.

Now you have two options to implement what you want -

  1. To check the replication status, tap into the replication queue as the code in /libs/cq/replication/components/revagent/revagent.jsp is doing. This is the code that executes on Author instance where the content is reverse replicated, in your case its Leader instance. You will have to works around this code to make it work on Worker instance. To be more specific on implementation your code will update the line Agent agent = agentMgr.getAgents().get(id); where id is the OUTBOX agent id.
  2. Have a event listener monitor the outbox. Check the payload that comes for replication and use it for your functionality.

What I have mentioned is the crude approach that doesn't cover the failover/recovery use-cases, i.e. how would you handle the deletion if your replication queue is blocked for any reason and the images have not been pushed back to leader.

Ameesh Trikha
  • 1,652
  • 2
  • 12
  • 18
  • If I were to do it using the 2nd solution, how can i check if the reverse replication is successful or not? – Arj Jul 22 '16 at 14:40