lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "SK R" <rsk....@gmail.com>
Subject Re: Does Lucene search over memory too?
Date Tue, 29 May 2007 08:45:20 GMT
Hi Michael McCandless,
    Thanks a lot for this clarification.
    Calling writer.flush() before every search is the solution for my case.
But this may cause any performance issues(i.e) more time or more memory
requirement?
    Any idea about time taken for writer.flush()?

Thanks & Regards
RSK

On 5/28/07, Michael McCandless <lucene@mikemccandless.com> wrote:
>
>
> Just to clarify: the answer to the original question is "no".  The
> searchers only see what's been flushed to the index directory, so,
> they will not search those docs still buffered in RAM of the writer.
> Calling writer.flush() and then recreating your searchers should work.
>
> The "autoCommit" mode for IndexWriter has not actually been released
> yet: you can only use it on the trunk.
>
> It actually serves a different purpose: it allows you to make sure
> your searchers do not see any changes made by the writer (even the
> ones that have been flushed) until you call close.  It defaults to
> autoCommit="true", which matches the current released Lucene
> behavior.
>
> Mike
>
> "Ard Schrijvers" <a.schrijvers@hippo.nl> wrote:
> > Hello,
> >
> > think you can find your answer in the IndexWriter API:
> >
> >
> http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/javadoc/org/apache/lucene/index/IndexWriter.html
> >
> > The optional autoCommit argument to the constructors  controls
> visibility
> > of the changes to IndexReader instances reading the same index. When
> this
> > is false, changes are not visible until close() is called. Note that
> > changes will still be flushed to the Directory as new files, but are not
> > committed (no new segments_N file is written referencing the new files)
> > until close() is called. If something goes terribly wrong (for example
> > the JVM crashes) before close(), then the index will reflect none of the
> > changes made (it will remain in its starting state). You can also call
> > abort(), which closes the writer without committing any changes, and
> > removes any index files that had been flushed but are now unreferenced.
> > This mode is useful for preventing readers from refreshing at a bad time
> > (for example after you've done all your deletes but before you've done
> > your adds). It can also be used to implement simple single-writer
> > transactional semantics ("all or none").
> >
> > Regards Ard
> >
> > >
> > > Hi,
> > >     Does Lucene search FSDirectory as well as buffered
> > > in-memory docs while
> > > we are calling searcher.search(query)?
> > >     Why I'm asking this is, I've indexed my doc with mergeFactor &
> > > Max.Buff.Docs = 50 and I've optimized and closed it at mid-night
> > > only.Beforeoptimization, my search gives partial matches and it does
> > > not give matches
> > > which is in memory.
> > >
> > >     To get all matches (inclusive of matches in memory),what
> > > i have to do?
> > >     Shall I use writer.flush() to resolve this?
> > >
> > > Thanks in Advance
> > >              RSK
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message