Not able to delete Asset in 6.3 AEM | Community
Skip to main content
U
user00725
Level 4
October 25, 2018
Solved

Not able to delete Asset in 6.3 AEM

  • October 25, 2018
  • 5 replies
  • 4516 views

Hi All,

In AEM 6.3 author, using assets console, https://<hostname>:<port>/assets.html/content/dam/xyz, when we are try to delete any image, its failing with error,  “Failed to delete.”

And when we check in browser console, we are seeing the exception, POST https://<hostname>:<port>/bin/wcmcommand 500 (Server Error)

And if we expand the failing call, in the network tab, it shows below exception

The query read more than 500000 nodes in memory. To avoid running out of memory, processing was stopped.

Cannot serve request to /bin/wcmcommand in

com.day.cq.wcm.core.impl.commands.WCMCommandServlet

Exception:

java.lang.UnsupportedOperationException: The query read more than 500000 nodes in memory. To avoid running out of memory, processing was stopped.

Above exceptions suggests, we are missing some indexes, that’s why its reading/traversing more nodes, when we try to delete an image.

Could you please suggest, what index we should create, to resolve this issue?

Regards

Sreeni

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 aneetarora

Hello sreeni​

The delete operation in AEM invokes a query in the background and considering the error you're facing, it appears that this query is running slow and/or running into query limits failing the delete operation.

The query that gets fired for this operation on an OOTB instance is something like

SELECT * FROM [nt:base] WHERE (ISSAMENODE(‘/content/dam/adobe-test/jpg3186.jpg’) OR ISDESCENDANTNODE(‘/content/dam/adobe-test/jpg3186.jpg’)) AND [cq:lastReplicationAction] = ‘Activate’

This query is being served by ntBaseLucene index and there has been issues raised in the past with the performance of this operation with this index. Further improvements will be included OOTB in the future,

In the meantime, the fix is to be on oak 1.6.5 or older, and then add -Doak.lucene.useActualEntryCount=true to the JVM parameter and restarting the server.

Best Regards,

Aneet Arora

5 replies

smacdonald2008
smacdonald2008
Level 10
October 25, 2018

This is indeed strange and something I ahve never seen personally. I will see if this is a known issue.

A
Adobe Employee
aneetaroraAdobe EmployeeAccepted solution
Adobe Employee
October 25, 2018

Hello sreeni​

The delete operation in AEM invokes a query in the background and considering the error you're facing, it appears that this query is running slow and/or running into query limits failing the delete operation.

The query that gets fired for this operation on an OOTB instance is something like

SELECT * FROM [nt:base] WHERE (ISSAMENODE(‘/content/dam/adobe-test/jpg3186.jpg’) OR ISDESCENDANTNODE(‘/content/dam/adobe-test/jpg3186.jpg’)) AND [cq:lastReplicationAction] = ‘Activate’

This query is being served by ntBaseLucene index and there has been issues raised in the past with the performance of this operation with this index. Further improvements will be included OOTB in the future,

In the meantime, the fix is to be on oak 1.6.5 or older, and then add -Doak.lucene.useActualEntryCount=true to the JVM parameter and restarting the server.

Best Regards,

Aneet Arora

    Lokesh_Shivalingaiah
    Lokesh_Shivalingaiah
    Level 10
    October 25, 2018

    Hi sreenivasula​

    aneeta45259594​ has explained in detail !

    Other option for you could be to raise a Daycare support ticket to see if they have any hotfix for the same.

    U
    user00725Author
    Level 4
    October 26, 2018

    Thank you Aneet Arora!

         The issue is solved. In fact this is a known issue in AEM 6.3 and there is an adobe Asset deletion hangs and takes more than a minute | AEM 6.3 helpex document on this.

    Thanks for your help!

    Regards

    Sreeni

    smacdonald2008
    smacdonald2008
    Level 10
    October 26, 2018

    Excellent reply Aneet and I am glad it's solved.

    Terms & ConditionsAccessibility statement

    Loading footer...