[jira] [Commented] (OAK-6225) Analyse changing the persistence format of GroupImpl

["angela (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-6225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16047552#comment-16047552 ] 

angela commented on OAK-6225:
-----------------------------

[~alex.parvulescu], some time ago I wrote an alternative PoCto change the persistence format of the group membership. You can look at it at https://github.com/anchela/jackrabbit-oak/commit/37cae3de6190a23aa6bc80e8074e814aeb9e8c13

I did run the benchmarks (specially 'addMembers') and found that the patch doesn't improve performance as much as I had expected. My interpretation was as follows:
- the lookup property is heavily prone to merge conflicts (see OAK-3381)
- the way new group members are introduced with that PoC will lead to splitting existing mv-properties and thus causes additional diffs compared to the original approach that just creates a new node/property pair.
- i tried to address the second point by increasing the threshold, which again led to OAK-3381.

so, once we have OAK-3381 fixed, i would rerun the benchmarks with this PoC and a bigger threshold... also: since the time i wrote the PoC, i added a lot more tests wrt user import, which rely on a storage formate... just marked as ignored for the time being.

> Analyse changing the persistence format of GroupImpl
> ----------------------------------------------------
>
>                 Key: OAK-6225
>                 URL: https://issues.apache.org/jira/browse/OAK-6225
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: Alex Parvulescu
>            Assignee: Alex Parvulescu
>             Fix For: 1.8
>
>         Attachments: groupimpl-v0.patch, groupimpl-v1.patch, groupimpl-v2.patch
>
>
> As suggested on OAK-3933, I'd like to look into using a different persistence format for the GroupImpl members.
> Currently this is saved as a list of child nodes, and I'd like to bench this against a tree based approach where each sub child node represents a part of the key so it can be used for lookup.
> WIP branch can be found at [0], I merged all the commits so far into a single one to reduce the noise.
> fyi [~anchela]
> [0] https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:oak-6225



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)