jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davide Giannella (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OAK-3380) Property index pruning should happen asynchronously
Date Tue, 04 Jun 2019 15:35:11 GMT

     [ https://issues.apache.org/jira/browse/OAK-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Davide Giannella updated OAK-3380:
    Fix Version/s: 1.16.0

> Property index pruning should happen asynchronously
> ---------------------------------------------------
>                 Key: OAK-3380
>                 URL: https://issues.apache.org/jira/browse/OAK-3380
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: property-index
>    Affects Versions: 1.3.5
>            Reporter: Vikas Saurabh
>            Priority: Minor
>              Labels: resilience
>             Fix For: 1.14.0, 1.16.0
> Following up on this (a relatively old) thread \[1], we should do pruning of property
index structure asynchronously. The thread was never concluded.. here are a couple of ideas
picked from the thread:
> * Move pruning to an async thread
> * Throttle pruning i.e. prune only once in a while
> ** I'm not sure how that would work though -- an unpruned part would remain as is until
another index happens on that path.
> Once we can move pruning to some async thread (reducing concurrent updates), OAK-2673
+ OAK-2929 can take care of add-add conflicts.
> ----
> h6. Why is this an issue despite merge retries taking care of it?
> A couple of cases which have concurrent updates hitting merge conflicts in our product
(Adobe AEM):
> * Some index are very volatile (in the sense that indexed property switches its values
very quickly) e.g. sling job status, AEM workflow status.
> * Multiple threads take care of jobs. Although sling maintains a bucketed structure for
job storage to reduce conflicts... but inside index tree the bucket structure, at times, gets
pruned and needs to be created in the next job status change
> While retries do take care of these conflict a lot of times and even when they don't,
AEM workflows has it's own retry to work around. But, retrying, IMHO, is just a waste of time
-- more importantly in paths where application doesn't really have a control.
> h6. Would this add to cost of traversing index structure?
> Yes, there'd be some left over paths in index structure between asynchronous prunes.
But, I think the cost of such wasted traversals would be covered up with time saved in avoiding
the concurrent update conflict.
> ----
> (cc [~tmueller], [~mreutegg], [~alex.parvulescu], [~chetanm])
> \[1]: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201506.mbox/%3CCADicHF66U2Vh-hLrJUNANsYtXfiDj2mT3vKTr4ybknGpzy9MNw@mail.gmail.com%3E

This message was sent by Atlassian JIRA

View raw message