You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "José Andrés Cordero Benítez (Jira)" <ji...@apache.org> on 2020/03/31 08:37:00 UTC
[jira] [Commented] (OAK-8984) A big number of NOOP changes can
result in a StackOverflow
[ https://issues.apache.org/jira/browse/OAK-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071594#comment-17071594 ]
José Andrés Cordero Benítez commented on OAK-8984:
--------------------------------------------------
I have added a possible fix for this issue. The test should be run using the JVM argument -Xss256k to reproduce the issue. After applying the fix, the StackOverflow exception should not appear anymore.
The fix tries to avoid unneeded wraps of newModifiedDocumentNodeState when there are not enough changes to persist.
> A big number of NOOP changes can result in a StackOverflow
> ----------------------------------------------------------
>
> Key: OAK-8984
> URL: https://issues.apache.org/jira/browse/OAK-8984
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
> Reporter: José Andrés Cordero Benítez
> Priority: Major
> Attachments: infinite-recursion-OAK-8984.patch
>
>
> We have a case where a sync job sometimes produce a StackOverflow when a big number of NOOP changes are executed. The problem could be related with the wrapping of a new ModifiedDocumentNodeState object in every call.
> If the number of changes don't reach the UpdateLimit value, if will continue creating objects until it throws a StackOverflow error.
> The problem only happens in very specific conditions, but with help of [~mreutegg] we were able to reproduce in a test that artificially recreates the situation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)