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.
Solved! Go to Solution.
Views
Replies
Total Likes
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-pos...) 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
Views
Replies
Total Likes
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-pos...) 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
Views
Replies
Total Likes
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:
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-pos...) 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.
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies