AEM Author Unresponsive

[jezwn]

Recently one of my clients faced an issue with AEM Author being unresponsive. The issue was resolved by restarting the server. However it was observed that before the server went down, there has been some authoring activity which was going on primarily around adding images and text in an accordion. The client had loaded around 60+ images and assets inside an accordion.
The traces from Adobe also indicated this specific page and the accordion component. What I would like to understand here is, is there any limitations to the accordion component in terms of how many items could be added inside? Or is it an authoring edge case? Or any other possible explanations?

[arunpatidar · Accepted solution]

Hi @jezwn 
I don't think so there is a limit to have limited node, there is a recommendations to not have more than 1000 immediate children nodes.
In your case the jcr is not the issue.

We have seen performance issue with component only if there is a data-sly-resource with resourcetpye in the HTL and that node does not exists

e.g. Could create performance

<section data-sly-resource="./path"></section>

the optimal one is

<section data-sly-resource="${'./path' @ resourceType='my/resource/type'}"></section>

[EstebanBustamante]

I agree with @arunpatidar. The traditional rule of "1000" children is likely a "recommendation/suggestion" that must be taken seriously, but technically not really a limitation.

What I have seen is that sometimes nesting components multiple times can lead to a circular dependency, which can, as you can imagine, cause the server to fail. However, usually, this issue is easy to reproduce even on a local machine. I am curious about what happened after you restarted and tried to open the page again? Does it break again? Were you able to reproduce this locally?

[Jörg_Hoh]

You should establish a procedure for such cases, which records a number in information from the runtime before the system is restarted. For example: do 5 thread-dumps in 2 second interval and also a heapdump.

Then you have more data you can check, as the logs often do not show what actually is going on.