What options are available for deleting left over nodes on a publisher instance? | Community
Skip to main content
LinearGradient
LinearGradient
Level 6
October 16, 2015
Solved

What options are available for deleting left over nodes on a publisher instance?

  • October 16, 2015
  • 4 replies
  • 3993 views

Hi,

A few days ago due to a bug in CQ5 one of the queues on our author instance got stuck so we were advised to clean it by deleting "/var/replication/data" and I think "/var/eventing/jobs".

However some of the items in the queue were calls to Deactivate, which as we cleaned the queue, din't get a chance to actually deactivate nodes from the publisher.

So now we have some left-over/orphaned nodes on the publisher instances.

What options are available for deleting such nodes?

Thanks.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Ove_Lindström

One way is to use the CRX Explorer found under http://localhost:4503/crx/explorer/browser/index.jsp. That is usefull if it is only a few publishers affected and a small number of nodes.

If the number of publishers is greater than one and the the nodes are more than a handfull, I would use cURL to manipulate on the nodes. Either you use the Sling Post Serlvet (http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html) or the -X command DELETE (curl -X DELETE http://localhost:4505/path/to/node/jcr:content/nodeName -u admin:admin assuming localhost and default password).

This can easily be scripted using a shell script and a csv file.

/Ove

4 replies

O
Ove_LindströmAccepted solution
Level 6
October 16, 2015

One way is to use the CRX Explorer found under http://localhost:4503/crx/explorer/browser/index.jsp. That is usefull if it is only a few publishers affected and a small number of nodes.

If the number of publishers is greater than one and the the nodes are more than a handfull, I would use cURL to manipulate on the nodes. Either you use the Sling Post Serlvet (http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html) or the -X command DELETE (curl -X DELETE http://localhost:4505/path/to/node/jcr:content/nodeName -u admin:admin assuming localhost and default password).

This can easily be scripted using a shell script and a csv file.

/Ove

LinearGradient
LinearGradientAuthor
Level 6
October 16, 2015

Hi Ove,

Thanks for the reply.

Ove Lindström wrote...

One way is to use the CRX Explorer found under http://localhost:4503/crx/explorer/browser/index.jsp. That is usefull if it is only a few publishers affected and a small number of nodes.

Do you mean finding the left over nodes manually and deleting them one by one? Of course we have already done this a few times, but we have over 5000 pages and this is not feasible anymore and it is also very error prone. We are looking for an automated solution. For example, a procedure like:

  • For each publisher
    • For every node under /content/myapp, /content/dam/myapp, etc.
      • If the node does not exist in the master author, delete it

While this might sound reasonable, there are plenty of edge cases and racing conditions under which this simple procedure can fail.

If the number of publishers is greater than one and the the nodes are more than a handfull, I would use cURL to manipulate on the nodes. Either you use the Sling Post Serlvet (http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html) or the -X command DELETE (curl -X DELETE http://localhost:4505/path/to/node/jcr:content/nodeName -u admin:admin assuming localhost and default password).

We are using curl through our Ansible scripts to provision and interact with CQ5 already, but as the "left over" nodes do not exist on author, there's not a meaningful path on author instances to which we can send the DELETE request. And the publish instances do not know if a node they have is a left over or not so sending a curl command to publishers won't work either.

This can easily be scripted using a shell script and a csv file.

/Ove

 

We might be forced to write an adhoc custom script to do so, but as this is a scenario that can happen quite often and as CQ is 10 years or so old, I was expecting to see an out-of-the box way to handle this (I was expecting CQ to prevent cases like this to start with, but as that's not the case, at least I was expecting it to come bundled with a utility to mitigate it).

I assume there's not anything out of the box available so we have to hack a custom script for our deployment, is this correct?

Thanks.

O
Ove_Lindström
Level 6
October 16, 2015

I agree that there should be some sort of syncronization process or "replay" option in the replication. Sending the deactivate or delete commands over the replicator again. We tried to do that, but if the node does not exist in the author invironment, then i refuses to send to the publishers. Highly annoying.

/Ove

trench999
trench999
Level 4
October 16, 2015

We agree completely.  This in an unacceptable gap in the product.  We should be able to configure the author to run a deactivate workflow on a delete event. We should then be able to setup a scheduled job to validate publish against activated nodes in author.  Adobe, please publish scripts, packages, etc to fill this gap.  

Terms & ConditionsAccessibility statement

Loading footer...