[ http://issues.apache.org/jira/browse/JCR-197?page=all ]
Marcel Reutegger resolved JCR-197:
----------------------------------
Resolution: Fixed
Index merging now runs in a daemon thread and does not block workspace save
operations anymore.
svn revision: 264144
> Index merging should run in a separate thread
> ---------------------------------------------
>
> Key: JCR-197
> URL: http://issues.apache.org/jira/browse/JCR-197
> Project: Jackrabbit
> Type: Improvement
> Components: query
> Environment: svn revision: 239657
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Priority: Minor
> Fix For: 1.0
>
> Indexes are merged using the configuration parameters mergeFactor and
> minMergeDocs. With the default value of 10 for mergeFactor and 100 for
> minMergeDocs, as soon as 10 index directories exist with less or equal than
> 100 nodes they are merged into a single one. This process is then repeated by
> multiplying the minMergeDocs with the mergeFactor. Therefore the second round
> will merge 10 index directories with less or equal than 1000 nodes.
> Because the above process is part of the regular workspace store operation an
> index merge with more than let's say 10'000 nodes can block the store
> operation for a couple of seconds. With the current synchronization scheme,
> all other threads are blocked from writing. This is not acceptable.
> Index merging should run in a separate thread in the background.
> The process needs to take care of the following:
> - While merging indexes, deletes on those indexes must not get lost
> - Switching between the indexes that are merged and the new index must be
> atomic
> - Recovery if merging is interrupted, e.g. jackrabbit is shutdown
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
