[jira] [Commented] (OAK-1456) Non-blocking reindexing
[
https://issues.apache.org/jira/browse/OAK-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956310#comment-13956310
]
Alex Parvulescu commented on OAK-1456:
--
This is how it should be enabled if needed (the oak-core version):
{code}
name = async-reindex;
task = new AsyncIndexUpdate(name, store, indexEditors, true);
scheduleWithFixedDelay(whiteboard, task, 5, true);
{code}
Non-blocking reindexing
---
Key: OAK-1456
URL: https://issues.apache.org/jira/browse/OAK-1456
Project: Jackrabbit Oak
Issue Type: Improvement
Components: query
Reporter: Michael Marth
Assignee: Alex Parvulescu
Priority: Blocker
Labels: production, resilience
Fix For: 0.20
Attachments: OAK-1456.patch
For huge Oak repos it will be essential to re-index some or all indexes in
case they go out of sync in a non-blocking way (i.e. the repo is still
operation while the re-indexing takes place).
For an asynchronous index this should not be much of a problem. One could
drop it and recreate (as an added benefit it might be nice if the user could
simply add a property reindex to the index definition node to trigger this).
For synchronous indexes, I suggest the mechanism creates an asynchronous
index behind the scenes first and once it has caught up
* blocks writes (?)
* removes the existing synchronous index
* moves asynchronous index in its place and makes it synchronous
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OAK-1456) Non-blocking reindexing
[ https://issues.apache.org/jira/browse/OAK-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13955146#comment-13955146 ] Alex Parvulescu commented on OAK-1456: -- The changes are in with rev 1583316. The only thing I've left out for now is the code that enables the background task. http://svn.apache.org/r1583316 Non-blocking reindexing --- Key: OAK-1456 URL: https://issues.apache.org/jira/browse/OAK-1456 Project: Jackrabbit Oak Issue Type: Improvement Components: query Reporter: Michael Marth Assignee: Alex Parvulescu Priority: Blocker Labels: production, resilience Fix For: 0.20 Attachments: OAK-1456.patch For huge Oak repos it will be essential to re-index some or all indexes in case they go out of sync in a non-blocking way (i.e. the repo is still operation while the re-indexing takes place). For an asynchronous index this should not be much of a problem. One could drop it and recreate (as an added benefit it might be nice if the user could simply add a property reindex to the index definition node to trigger this). For synchronous indexes, I suggest the mechanism creates an asynchronous index behind the scenes first and once it has caught up * blocks writes (?) * removes the existing synchronous index * moves asynchronous index in its place and makes it synchronous -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OAK-1456) Non-blocking reindexing
[ https://issues.apache.org/jira/browse/OAK-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13955198#comment-13955198 ] Alex Parvulescu commented on OAK-1456: -- Just to sum up, the remaining question is mostly about whether this background thread should be enabled by default in oak or not, and if so how frequently should it run. Non-blocking reindexing --- Key: OAK-1456 URL: https://issues.apache.org/jira/browse/OAK-1456 Project: Jackrabbit Oak Issue Type: Improvement Components: query Reporter: Michael Marth Assignee: Alex Parvulescu Priority: Blocker Labels: production, resilience Fix For: 0.20 Attachments: OAK-1456.patch For huge Oak repos it will be essential to re-index some or all indexes in case they go out of sync in a non-blocking way (i.e. the repo is still operation while the re-indexing takes place). For an asynchronous index this should not be much of a problem. One could drop it and recreate (as an added benefit it might be nice if the user could simply add a property reindex to the index definition node to trigger this). For synchronous indexes, I suggest the mechanism creates an asynchronous index behind the scenes first and once it has caught up * blocks writes (?) * removes the existing synchronous index * moves asynchronous index in its place and makes it synchronous -- This message was sent by Atlassian JIRA (v6.2#6252)
