Expand my Community achievements bar.

Radically easy to access on brand approved content for distribution and omnichannel performant delivery. AEM Assets Content Hub and Dynamic Media with OpenAPI capabilities is now GA.
SOLVED

AEM 6.5 Maximum size of node exceeded- greater than 102400

Avatar

Level 10

Hi 

we have an old application where paths are stored as string[] within a node and we receive an error along the lines 

WARN [async-index-update-fulltext-async] org.apache.jackrabbit.oak.plugins.index.lucene.LuceneDocumentMaker String length: xxx for property: proplist at Node: xxx is greater than configured value 102400

 

Was referring to this url 

 

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/what-s-the-maximum-size-of...

 

while I know of the limitations, wondering if there are ways one could guide with refactoring say approach with binary file or so while maintaining backwards compatibility and perhaps indexing that was set as well ? 


Is this something that can potentially bring down the instance  ? 

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

This is just a warning, indicating there is a large non-binary property. Not sure if it even indicates that something is not working at all ... (would need to test that). But the worst which can happen is that this property is not completely indexed (so you won't find every entry of that property if you search via JCR for it). But it's not a stability problem per se. Unless you make it 10s of megabytes large, at which point it could turn into a memory issue.

View solution in original post

5 Replies

Avatar

Community Advisor

@NitroHazeDev One suggestion is you could write some script to convert the string array into json and save it in DAM and read the JSON in your page/component and process it. 

Avatar

Correct answer by
Employee Advisor

This is just a warning, indicating there is a large non-binary property. Not sure if it even indicates that something is not working at all ... (would need to test that). But the worst which can happen is that this property is not completely indexed (so you won't find every entry of that property if you search via JCR for it). But it's not a stability problem per se. Unless you make it 10s of megabytes large, at which point it could turn into a memory issue.

Avatar

Level 10

There is no problem with functionality but I see 2400 ish semicolon separated paths starting with /content/ . Does the 102400 include every character , I believe so .. it is not indexed and is used for sitemap ( old ways) to exclude paths that should not be exposed in the sitemap file exposed via pubs .. this this contains 2400 paths to be excluded from display .. what do you suggest @Jörg_Hoh .. the warning came up in looking glass for some index 

 

I was thinking of storing strings in binary file under the sitemap component node within content structure .. 

Avatar

Level 10

Tried a quick poc and noticed storing as a binary property or a file with jcr data worked .. thanks all