FAQ
Hi,

In an attempt to balance searching efficiency against the number of open file descriptors on my system, I cache IndexSearchers with a "last used" timestamp. A background cache manager thread then periodically checks the cache for any that haven't been used in a while and removes them from the cache. In so doing, it also closes their underlying IndexReaders to force the files to be released. This works very well, but I have hit a very occasional race condition where search code grabs a searcher from the cache just as it is about to expire - causing an "AlreadyClosed" exception. Rather than attempt to synchronize my code, I figured it might be less expensive if search() (I have extended IndexSearcher) were to check that the underlying IndexReader is still open - and reopen() if necessary. However, I cannot find a way to detect this ... is there a way? Failing that, what is the cost of just issuing a reopen() anyway?

Thanks for any thoughts / ideas.

- Chris

Search Discussions

  • Chris Hostetter at Oct 6, 2009 at 7:00 pm
    : I figured it might be less expensive if search() (I have extended
    : IndexSearcher) were to check that the underlying IndexReader is still

    if you're extending IndexSearcher anyway you can override the close()
    method to update a boolean and then add your own isClosed() method.

    : open - and reopen() if necessary. However, I cannot find a way to

    FWIW: I don't believe you can call the reopen() method on a close
    IndexReader ... but you can of course "re" open a new IndexReader
    instance.

    : detect this ... is there a way? Failing that, what is the cost of just
    : issuing a reopen() anyway?

    if the index hasn't changed, it's free. If the index has changed
    a lot, it's as expensive as open() ... if there are minor changes then
    it's somewhere in between.



    -Hoss


    ---------------------------------------------------------------------
    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
postedOct 1, '09 at 12:53p
activeOct 6, '09 at 7:00p
posts2
users2
websitelucene.apache.org

2 users in discussion

Chris Bamford: 1 post Chris Hostetter: 1 post

People

Translate

site design / logo © 2022 Grokbase