lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ning Li (JIRA)" <>
Subject [jira] Commented: (LUCENE-1335) Correctly handle concurrent calls to addIndexes, optimize, commit
Date Mon, 25 Aug 2008 18:37:44 GMT


Ning Li commented on LUCENE-1335:

> I don't think so: with autoCommit=true, the merges calls commit(long)
> after finishing, and I think we want those commit calls to run
> concurrently?

After we disable autoCommit, all commit calls will be serialized, right?

> What'll happen is the BG merge will hit an exception, roll itself
> back, and then the FG thread will pick up the merge and try again.
> Likely it'll hit the same exception, which is then thrown back to the
> caller.  It may not hit an exception, eg say it was disk full: the BG
> merge was probably trying to merge 10 segments, whereas the FG merge
> is just copying over the 1 segment.  So it may complete successfully
> too.

Back to the issue of running an external merge in BG or FG.
In ConcurrentMergeScheduler.merge, an external merge is run in FG,
not in BG. But in,
whether a merge is external is no longer checked. Why this difference?

> Correctly handle concurrent calls to addIndexes, optimize, commit
> -----------------------------------------------------------------
>                 Key: LUCENE-1335
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 2.3, 2.3.1
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>            Priority: Minor
>             Fix For: 2.4
>         Attachments: LUCENE-1335.patch, LUCENE-1335.patch, LUCENE-1335.patch, LUCENE-1335.patch
> Spinoff from here:

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message