Highlighted

AEM 6.1 - Deactivate only deleting jcr:content, not page node

Avatar

Avatar

robertf46710686

Avatar

robertf46710686

robertf46710686

27-12-2016

I am stumped....

On a page deactivation only the jcr:content node of the page concerned is deleted, not the page itself.  I've been completely through our code and cannot find anything that would interfere with the deactivation process.  In the AEM log and OSGi event log I get the normal, expected messages:

publish AEM log:

28.12.2016 06:38:47.765 *INFO* [172.17.0.1 [1482907127763] POST /bin/receive HTTP/1.1] com.day.cq.replication.impl.ReplicationReceiverImpl removeRecursive(/content/mypath/my_page) done: 21 nodes deleted, saving...
28.12.2016 06:38:47.770 *INFO* [172.17.0.1 [1482907127763] POST /bin/receive HTTP/1.1] com.day.cq.replication.impl.servlets.ReplicationServlet Processed replication action in 6ms: DEACTIVATE of /content/mypath/my_page
28.12.2016 06:38:47.773 *DEBUG* [Adobe Granite ChainReplicationService Processor] com.day.cq.replication.impl.ChainReplicationService Queue is too young. waiting another 1997ms.
28.12.2016 06:38:49.770 *DEBUG* [Adobe Granite ChainReplicationService Processor] com.day.cq.replication.impl.ChainReplicationService Processing 1 queue entries
28.12.2016 06:38:49.770 *DEBUG* [Adobe Granite ChainReplicationService Processor] com.day.cq.replication.impl.ChainReplicationService Chain-Replicating DEACTIVATE of /content/mypath/my_page
28.12.2016 06:38:49.770 *DEBUG* [Adobe Granite ChainReplicationService Processor] com.day.cq.replication.impl.ChainReplicationService No agent selected.
28.12.2016 06:38:49.770 *DEBUG* [Adobe Granite ChainReplicationService Processor] com.day.cq.replication.impl.ChainReplicationService Queue is empty - waiting for modifications.

OSGi events:

lots or ResourceRemoved then:

      
12/28/2016, 7:10:04 AMcom/day/cq/wcm/core/page         
event.topicscom/day/cq/wcm/core/page
modifications[{path=/content/my_path/my_page, modifiedDate=Wed Dec 28 06:10:04 UTC 2016, type=PageDeleted, userId=admin}]

Since the replication is running as admin that rules out permissions problems.

Can anyone suggest anything to check or method to help debug this? Perhaps I am missing a configuration somewhere?

 

Additional info:

Author is logging a normal 200 success, and reports the page activated/deactivated as normal.  

System is AEM 6.1 SP2.  Standard OOTB replication config, localhost instances.

Replies

Highlighted

Avatar

Avatar

tushark60575350

Avatar

tushark60575350

tushark60575350

28-12-2016

I am also facing the same issue, but one pattern I have seen if you deactivate a page and that page has child pages which are in activated state then only this behavior happens i.e. the parent page doesn't get deleted and only the jcr:content gets deleted.

Please let me know if you find any solution for it.

Highlighted

Avatar

Avatar

robertf46710686

Avatar

robertf46710686

robertf46710686

29-12-2016

Will do, but don't hold your breath! Likewise if you get a flash of inspiration please do let me know.

Highlighted

Avatar

Avatar

raja_vijay_sing

Avatar

raja_vijay_sing

raja_vijay_sing

29-12-2016

Deactivation doesn't deactivate the sub folders, so this should be expected, as you need the parent node for the sub pages.. if you deactivate the child nodes and try. i believe this shouldn't happen

Highlighted

Avatar

Avatar

robertf46710686

Avatar

robertf46710686

robertf46710686

29-12-2016

@raja vijay singh.  If I understand correctly what you're saying then I think you're wrong - In a standard AEM 6.1 Geometrixx install (using the demo machine), deactivating a page will also deactivate the sub-pages, completely - not just the jcr:content node.  Something is misconfigured / reconfigured / causing unlogged errors somewhere, but I can't find where 😞

Highlighted

Avatar

Avatar

raja_vijay_sing

Avatar

raja_vijay_sing

raja_vijay_sing

29-12-2016

@robert,

My bad, I confused between activate and deactivate.. if you activate a child page without activating the parent page.. you will see this kind of scenario.