FAQ
Hi, all

I've got a question here needing your help:
For my index, I opened one IndexWriter (autocommit mode) and one
IndexSearcher on it;
I have quite a lot of threads here concurrently writing new documents and
doing search in index.
the IndexWriter is flushed periodically.
as I want the IndexSearcher be able to see the latest record, I also need to
periodically reopen the underlying IndexReader.

But is it safe to just call close() on the IndexSearcher when there are
still threads using it?

or maybe I should use atomic counter to make sure there's no thread using it
before calling close() on IndexSearcher?

thanks.

Search Discussions

  • John Griffin at Feb 17, 2008 at 5:17 am
    Your users won't appreciate your closing the searcher on them. That is, if
    you have a highly concurrent system.

    I don't know about 2.3.0 yet. Haven't had much chance to see the changes but
    with 2.2.0 I use an atomic counter. It's not that much to program.

    Regards,
    John G.


    -----Original Message-----
    From: ZaeX
    Sent: Saturday, February 16, 2008 2:32 AM
    To: java-user@lucene.apache.org
    Subject: how to safely periodically reopen the IndexReader?

    Hi, all

    I've got a question here needing your help:
    For my index, I opened one IndexWriter (autocommit mode) and one
    IndexSearcher on it;
    I have quite a lot of threads here concurrently writing new documents and
    doing search in index.
    the IndexWriter is flushed periodically.
    as I want the IndexSearcher be able to see the latest record, I also need to
    periodically reopen the underlying IndexReader.

    But is it safe to just call close() on the IndexSearcher when there are
    still threads using it?

    or maybe I should use atomic counter to make sure there's no thread using it
    before calling close() on IndexSearcher?

    thanks.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Robert Hastings at Feb 18, 2008 at 5:09 pm
    We have the same situation and use an atomic counter. Basically, we have
    a SearcherHolder class and a SearcherManager class. The SearcherHolder
    holds the searcher and the number of threads referencing the searcher.

    When the thread that writes to the index closes the index, it sends an
    event that the SearcherManager is listening for. The next time a search
    is performed the manager opens a new searcher. The old searcher is marked
    as outdated but is not closed until the last thread that references the
    searcher returns it.





    ZaeX <zaexage@gmail.com>
    02/16/2008 03:32 AM
    Please respond to
    java-user@lucene.apache.org


    To
    java-user@lucene.apache.org
    cc

    Subject
    how to safely periodically reopen the IndexReader?






    Hi, all

    I've got a question here needing your help:
    For my index, I opened one IndexWriter (autocommit mode) and one
    IndexSearcher on it;
    I have quite a lot of threads here concurrently writing new documents and
    doing search in index.
    the IndexWriter is flushed periodically.
    as I want the IndexSearcher be able to see the latest record, I also need
    to
    periodically reopen the underlying IndexReader.

    But is it safe to just call close() on the IndexSearcher when there are
    still threads using it?

    or maybe I should use atomic counter to make sure there's no thread using
    it
    before calling close() on IndexSearcher?

    thanks.
  • Zaexage at Feb 21, 2008 at 2:52 am
    Yes, I'm using a solution quite similar to this one. :)

    But when I read the Lucene 2.3 IndexReader.java code and javadoc, I
    see they have added a synchronous reference-counter to IndexReader and
    when it drops to zero, this instance will automatically call doClose()
    to clean, but the manipulator methods of this counter is marked as
    `protected'.
    I thought of extending FilterIndexReader to use the inherited counter
    manipulator. Has anyone tried this way?

    2008/2/19, Robert.Hastings@ancept.com <Robert.Hastings@ancept.com>:
    We have the same situation and use an atomic counter. Basically, we have
    a SearcherHolder class and a SearcherManager class. The SearcherHolder
    holds the searcher and the number of threads referencing the searcher.

    When the thread that writes to the index closes the index, it sends an
    event that the SearcherManager is listening for. The next time a search
    is performed the manager opens a new searcher. The old searcher is marked
    as outdated but is not closed until the last thread that references the
    searcher returns it.





    ZaeX <zaexage@gmail.com>
    02/16/2008 03:32 AM
    Please respond to
    java-user@lucene.apache.org


    To
    java-user@lucene.apache.org
    cc

    Subject
    how to safely periodically reopen the IndexReader?






    Hi, all

    I've got a question here needing your help:
    For my index, I opened one IndexWriter (autocommit mode) and one
    IndexSearcher on it;
    I have quite a lot of threads here concurrently writing new documents and
    doing search in index.
    the IndexWriter is flushed periodically.
    as I want the IndexSearcher be able to see the latest record, I also need
    to
    periodically reopen the underlying IndexReader.

    But is it safe to just call close() on the IndexSearcher when there are
    still threads using it?

    or maybe I should use atomic counter to make sure there's no thread using
    it
    before calling close() on IndexSearcher?

    thanks.
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org
  • Stephane Nicoll at Feb 21, 2008 at 8:37 am

    On Mon, Feb 18, 2008 at 6:08 PM, wrote:
    We have the same situation and use an atomic counter. Basically, we have
    a SearcherHolder class and a SearcherManager class. The SearcherHolder
    holds the searcher and the number of threads referencing the searcher.

    When the thread that writes to the index closes the index, it sends an
    event that the SearcherManager is listening for. The next time a search
    is performed the manager opens a new searcher. The old searcher is marked
    as outdated but is not closed until the last thread that references the
    searcher returns it.
    That sounds interesting. Couldn't it be part of the core capabilities
    of Lucene?

    Stéphane


    --
    Large Systems Suck: This rule is 100% transitive. If you build one,
    you suck" -- S.Yegge

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-user-help@lucene.apache.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupjava-user @
categorieslucene
postedFeb 16, '08 at 9:32a
activeFeb 21, '08 at 8:37a
posts5
users4
websitelucene.apache.org

People

Translate

site design / logo © 2022 Grokbase