This conversation has been locked due to inactivity. Please create a new post.
This conversation has been locked due to inactivity. Please create a new post.
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
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 ?
Solved! Go to Solution.
Views
Replies
Total Likes
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.
@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.
thanks @Saravanan_Dharmaraj , ended up storing it as binary under the same node
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.
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 ..
Tried a quick poc and noticed storing as a binary property or a file with jcr data worked .. thanks all
Views
Likes
Replies