AEM 6.5 Maximum size of node exceeded- greater than 102400 | Community
Skip to main content
N
NitroHazeDev
Level 9
March 26, 2023
Solved

AEM 6.5 Maximum size of node exceeded- greater than 102400

  • March 26, 2023
  • 2 replies
  • 2896 views

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-a-node-in-jcr-aem-aem-community-blog/td-p/459690

 

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  ? 

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 joerghoh

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.

2 replies

Saravanan_Dharmaraj
Community Advisor
Saravanan_DharmarajCommunity Advisor
Community Advisor
March 26, 2023

@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. 

    N
    NitroHazeDevAuthor
    Level 9
    April 4, 2023

    thanks @saravanan_dharmaraj ,  ended up storing it as binary under the same node 

      joerghoh
      Adobe Employee
      joerghohAdobe EmployeeAccepted solution
      Adobe Employee
      March 31, 2023

      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.

        N
        NitroHazeDevAuthor
        Level 9
        April 1, 2023

        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 @joerghoh .. 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 .. 

          N
          NitroHazeDevAuthor
          Level 9
          April 3, 2023

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

            Terms & ConditionsAccessibility statement

            Loading footer...