> Or instead of "shutdown" it's more of a "interrupt the
> merge if it's in progress" which then doesn't prevent further IO?
At a high level, this would seem like the most valuable approach. But I
think we would want to distinguish between writing new documents and
merges of existing segments. The
"Doron Cohen" <[EMAIL PROTECTED]> wrote:
>
> "Michael McCandless" wrote:
>
> > That's correct.
> >
> > On seeing the "shutdown in progress" exception, the current "finally"
> > clause in mergeSegments would revert the internal state of the
> > IndexWriter to be consistent, ie, put back the segment
"Michael McCandless" wrote:
> That's correct.
>
> On seeing the "shutdown in progress" exception, the current "finally"
> clause in mergeSegments would revert the internal state of the
> IndexWriter to be consistent, ie, put back the segments that were in
> the process of being merged into its seg
"Doron Cohen" <[EMAIL PROTECTED]> wrote:
> Michael McCandless wrote on 23/May/2007:
>
> > Actually if autoCommit=true then the only choice is to keep
> > the partial work. In this mode, optimize indeed goes in
> > "stages" (merging mergeFactor segments at a time) and after
> > each stage it commi
Michael McCandless wrote on 23/May/2007:
> Actually if autoCommit=true then the only choice is to keep
> the partial work. In this mode, optimize indeed goes in
> "stages" (merging mergeFactor segments at a time) and after
> each stage it commits a new segments_N file and removes the
> now-merged
Michael Busch wrote on 17/May/2007:
> public static class ExtendedFSDirectory extends FSDirectory {
> ...
> public void flushBuffer(byte[] b, int offset, int size)
> throws IOException {
> if (ExtendedFSDirectory.this.interrupted) {
> throw new IndexWriterInterruptException();
> }
>
>
"Steven Parkes" <[EMAIL PROTECTED]> wrote:
> As to what happens in the middle of a merge or optimize: I think it
> might depend on the autoCommit flag. Since an optimize may be done
> in stages, whether the intermediary stages are kept or not is going
> to depend on when the segments file gets upd
Steven Parkes wrote:
I'm not certain, but would parts of your goal be achieved by the work
i've
seen floating arround Jira to refactor th MergePolicy so that it can
be
handled by multiple thrads?
Well, in what I've been working on for LUCENE-847 (merge policy
factoring)
> I'm not certain, but would parts of your goal be achieved by the work
i've
> seen floating arround Jira to refactor th MergePolicy so that it can
be
> handled by multiple thrads?
Well, in what I've been working on for LUCENE-847 (merge policy
factoring) and LUCENE-870 (concurrent merge policy),
Doron Cohen wrote:
Antony Bowesman wrote:
Another use this may have is that mini-optimize operations could be
done at more
regular intervals to reduce the time for a full optimize. I could
then schedule
mini-optimise to run for a couple of minutes at more frequent intervals.
This seems to ass
Antony Bowesman wrote:
> Another use this may have is that mini-optimize operations could be
> done at more
> regular intervals to reduce the time for a full optimize. I could
> then schedule
> mini-optimise to run for a couple of minutes at more frequent intervals.
This seems to assume the propo
Michael Busch wrote:
Hi,
if you run Lucene as a service you want to be able to shut it down in a
certain period of time (usually 1-2 mins). This can be a problem if the
IndexWriter is in the middle of a merge when the service shutdown
request is received.
My question is if people think tha
I'm not certain, but would parts of your goal be achieved by the work i've
seen floating arround Jira to refactor th MergePolicy so that it can be
handled by multiple thrads? ... if MergePolicies are refactored into their
own class with ways of indicating when/if/how a merge should be done, then
p
Hi,
if you run Lucene as a service you want to be able to shut it down in a
certain period of time (usually 1-2 mins). This can be a problem if the
IndexWriter is in the middle of a merge when the service shutdown
request is received.
Therefore it would be nice if we had a method in IndexWri
14 matches
Mail list logo
