That should be fine!
Mike
On Fri, Feb 26, 2010 at 3:26 PM, Peter Keegan wrote:
> Can IW.waitForMerges be called between 'prepareCommit' and 'commit'? That's
> when the app calls 'getReader' to create external data.
>
> Peter
>
> On Fri, Feb 26, 2010 at 3:15 PM, Peter Keegan wrote:
>
>> Great, I
Can IW.waitForMerges be called between 'prepareCommit' and 'commit'? That's
when the app calls 'getReader' to create external data.
Peter
On Fri, Feb 26, 2010 at 3:15 PM, Peter Keegan wrote:
> Great, I'll give it a try.
> Thanks!
>
>
> On Fri, Feb 26, 2010 at 3:11 PM, Michael McCandless <
> luc
Great, I'll give it a try.
Thanks!
On Fri, Feb 26, 2010 at 3:11 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> Note that it's a BG merge (not commit)...
>
> You can use the new (as of 2.9 I think) IndexWriter.waitForMerges API?
> If you call that, then call .getReader().getVersion(
Note that it's a BG merge (not commit)...
You can use the new (as of 2.9 I think) IndexWriter.waitForMerges API?
If you call that, then call .getReader().getVersion(), then close &
open the writer, I think (but you better test to be sure!) the next
.getReader().getVersion() should always match.
Is there a way for the application to wait for the BG commit to finish
before it calls IW.close? If so, would this prevent the extra version? The
extra version causes the app. to think that the external data it committed
is out of synch with the index, which requires the app to do extra
processing
OK -- I can now see what happened.
There was a merge still running, when you called IW.commit (Lucene
Merge Thread #0). Because IW.commit does not wait for BG merges to
finish, but IW.close does (by default), this means you'll pick up an
extra version whenever a merge is running when you call clo
I'm pretty sure this output occurred when the version number skipped +1.
The line containing ''. separates the close/open IndexWriter.
IFD [Indexer]: setInfoStream
deletionpolicy=org.apache.lucene.index.keeponlylastcommitdeletionpol...@646f9dd9
IW 9 [Indexer]: setInfoStream:
dir=org.ap
Do you know the place in the infoStream output where you got a reader
with the wrong (unexplained extra +1) version? If so, can you post
the infoStream output up to that point?
Mike
On Thu, Feb 25, 2010 at 10:22 AM, Peter Keegan wrote:
> I've reproduced this and I have a bunch of infoStream log
I've reproduced this and I have a bunch of infoStream log files. Since the
messages have no timestamps, it's hard to tell where the relevant entries
are. What should I be looking for?
Peter
On Mon, Feb 22, 2010 at 3:58 PM, Peter Keegan wrote:
> I'm pretty sure there are flushes and segment merge
I'm pretty sure there are flushes and segment merges going on, but as you
said, that shouldn't affect the version increment. I'll see what I can do to
get infoStream output.
Thanks,
Peter
On Mon, Feb 22, 2010 at 2:30 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> Well I'm at a loss
Well I'm at a loss then. The version should only increment on commit.
Can you make it all happen when infoStream is on, and post back?
Mike
On Mon, Feb 22, 2010 at 12:35 PM, Peter Keegan wrote:
> Only one writer thread and one writer process.
> I'm calling IndexWriter(Directory d, Analyzer a,
Only one writer thread and one writer process.
I'm calling IndexWriter(Directory d, Analyzer a, boolean create,
MaxFieldLength mfl), which sets autocommit=false.
Peter
On Mon, Feb 22, 2010 at 12:24 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> That's curious.
>
> It's only on prep
That's curious.
It's only on prepareCommit (or, commit, if you didn't first prepare,
since that will call prepareCommit internally) that this version
should increase.
Is there only 1 thread doing this?
Oh, and, are you passing false for autoCommit?
Mike
On Mon, Feb 22, 2010 at 11:43 AM, Peter
Peter,
Perhaps other concurrent operations?
Jason
On Tue, Feb 23, 2010 at 10:43 AM, Peter Keegan wrote:
> Using Lucene 2.9.1, I have the following pseudocode which gets repeated at
> regular intervals:
>
> 1. FSDirectory dir = FSDirectory.open(java.io.File);
> 2. dir.setLockFactory(new SingleIn
14 matches
Mail list logo
