[
https://issues.apache.org/jira/browse/OAK-10657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17819279#comment-17819279
]
Stefan Egli commented on OAK-10657:
-----------------------------------
So for reading simplicity I guess this in the context of the stack trace
mentioned in [another
comment|https://issues.apache.org/jira/browse/OAK-10642?focusedCommentId=17819206&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17819206]
?
Then I'd say having a new type would be feasible. That (the handler code of
that new exception type) could then invoke the "util" that can provide
UpdateOps for cleanup (which itself could be in or near "DetailedGC territory"
- as that could be needed there too).
And I'm guessing we're looking at doing it at exception time because ... we
don't have the (before) document at hand for inspecting large properties
_before_ we're sending the update?
So having an "exception time" handling (this 4th approach) sounds feasible.
Having said that, I'm wondering about some other approaches:
* 5. upon successful branch commit we'd have the actual before document(s), so
we could inspect them for large properties. We could treat that similar to how
splits are handled (Commit.checkSplitCandidate). That might be what is already
covered under the 1st appraoch though (make GC more aggressive) ...
* 6. in a variation to 5.: could we start collecting large (eg 1k) property
updates in the branch (eg DocumentNodeStoreBranch) after a successful branch
commit - so that in case we'll update that same property in the same branch
again, we'd actually have some infos and could proactively remove the previous
branch commit, besides having applying the new one. This could catch a majority
of cases in a non intrusive way.
> MongoDocumentStore: shrink in-DB documents after updates fail due to 16MB
> limit
> -------------------------------------------------------------------------------
>
> Key: OAK-10657
> URL: https://issues.apache.org/jira/browse/OAK-10657
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, mongomk
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Major
>
> To address the 16MB/childorder issue, there are many potential approaches:
> - make GC more aggressive
> - try to change updates to remove "in-between" changes of ":childOrder"
> property
> - change the data model of ":childOrder"
> - try to shrink document in DB once size related exception happens
> This ticket is about the last of these options.
> Proposal:
> - improve exception thrown by document store so that it can be acted upon
> - in document store utils add a method that inspects a document and produces
> UpdateOps suitable to shrink the document
> - DocumentNodeStore commit could catch exception, obtain update ops, apply
> them, and retry once (this should be dependant on a feature toggle)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
