[
https://issues.apache.org/jira/browse/OAK-2663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-2663:
---------------------------------
Attachment: OAK-2663.patch
proposed patch.
The idea behind this is to apply the unique keys directly to the index on each
level and at the same time record possible conflicts. this will reduce
buffering of the keys by quite a lot. The possible conflicts will be rechecked
at the end to filter out valid operations (like node moves). patch passes all
tests.
as a side note my heavy upgrade test of a 13M nodes repo (same as Chetan's)
falls down from 35 mins to under 29 mins, but as mentioned gains on Mongo might
be higher. cc [~chetanm]
> Unique property index can trigger OOM during upgrade of large repository
> ------------------------------------------------------------------------
>
> Key: OAK-2663
> URL: https://issues.apache.org/jira/browse/OAK-2663
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: upgrade
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Fix For: 1.1.8
>
> Attachments: OAK-2663.patch
>
>
> {{PropertyIndexEditor}} when configured for unique index maintains an in
> memory state of indexed property in {{keysToCheckForUniqueness}}. This set
> would accumulate all the unique values being indexed.
> In case of upgrade where the complete upgrade is performed in single commit
> this state can become very large. Further later while exiting the editor
> validates that all such values are actually unique by iterating over all such
> values.
> We should look into other possible ways to enforce uniqueness constraint
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
