Troubleshooting the 200-Node Limit that Breaks AEM Assets Metadata Form Schema Import

2 replies
17 views
Translate All

Sharing a specific AEM Assets issue I ran into and its solution.

Steps to reproduce the issue:

Goto https://experience.adobe.com/?repoId=author-pXX-eXX.adobeaemcloud.com#/@myorg/assets/importmetadataform/
The environment should have more than 600 user groups with ACE permissions.
Hit Import metadata
Import will throw this error

Root cause:

Specifically https://author-pXX-eXX.adobeaemcloud.com/conf/global/settings/dam/adminui-extension/metadataschema/rep:policy.-1.json this request returns 300. While loading the import wizard, the Assets viewer tries to load complete rep:policy under metadataschema to show allowed schemas. This is an expensive operation and throws 300, if the number of nodes under /conf/global/settings/dam/adminui-extension/metadataschema/rep:policy is more than default 200 nodes

Fix:

The current bandage to fix this issue is to bump the max nodes for GetDefaultServlet to larger number. Create an osgi config under apps/myapp/osgiconfig/config.author/org.apache.sling.servlets.get.DefaultGetServlet.cfg.json and add an entry

{
  "json.maximumresults:Integer":2500
}

This will allow the rep:policy.-1.json to load 200 instead of 300 and will fix the error.

shrutid56001193

User Group Leader

Thanks for sharing, nice find! A couple of small additions:

The 300 is the HTTP status “Multiple Choices” that Sling returns when a .-1.json request hits the result limit. With the higher limit you get a 200 again.
json.maximumresults applies to all JSON dumps on author, so better to keep it as low as works. Check the current DefaultGetServlet config from the Developer Console first, so other values don’t get reset.
Long term thinking: whether those 600 groups really each need their own ACE on the metadata schema folder. A few parent groups holding the ACEs would fix it without touching Sling.

Translate

https://www.shrutidamle.com/

sarav_prakash

Author

Community Advisor

Thanks @shrutid56001193 for sharing. Valid ask, why a client should use 600 groups. They had a 6 levels for each team, so every time a team onboards, repoinit was creating 6 groups. It was their lower UAT environment, unmanaged for 5-6 years.

But issue is not with count of groups. I could reproduce with just 10 groups, but with strenuous multiple ACE policies that increases `/rep:policy` with >200 nodes.

Constraint is the default 200 node limit causing 300.

Long term ideal fix, should be, AEM Assets portal should gracefully handle 300s. 300 is not a failure. Instead when the portal sees 300, it should further fetch inner jsons and consolidate. I would still consider, this is a product bug, Assets is not gracefully handling 300s; rather than strangling clients to reduce groups or policies.

Translate

Sign up

Login with SSO

Login to the community

Login with SSO