If you are using a more recent version of Lucene you might check out
https://issues.apache.org/jira/browse/LUCENE-1026 and try the
WarmingIndexAccessor. Even if you don't use it, it will serve as a
decent example.
Ian Lea wrote:
Hi
I think that you will need to close your reader objects. Hanging on
to them may prevent files from being deleted and you are likely to hit
memory or open file limitations.
We generally use a low tech approach:
save reference to old reader/searcher
create new one and give that out to those who want it
sleep for as long as longest searches normally take
close old reader.
Works for us.
--
Ian.
P.S. Please don't post same message twice.
On Wed, May 28, 2008 at 9:21 AM, Christian Reuschling
<[EMAIL PROTECTED]> wrote:
Hello out there,
We have implemented some open source desktop searching app based on Lucene
http://sourceforge.net/projects/dynaq
Development always goes further, and currently we make experiments with the
file-lock based writer (/reader) synchronization capabilities of Lucene, in
order to waste our current synchronization method, which is not such
comfortable
to use.
I have a global writer Object and an according Reader, which is also global
accessible inside the application. For both there are getter methods, inside
the getReader() method we check with reader.isCurrent() whether there are
modifications inside the index or not. In the case there are modifications,
I close the reader and create a new one, returning it.
And this is exactly the problem. In the case there are still some references
to the old reader object, I get an IndexAlreadyClosedException.
I'm thinking for a while about this problem, and have also searched long
time
inside the Lucene mailing list repository. The root of the problem is not to
close a reader Object if there is at least one reference to it left.
To ensure this, for my impression, we have the following possibilities:
1. Add a new method 'release reader' and count whether there are some
unreleased
reader Objects left. Only close if not. This makes coding much less
comfortable,
if you forget to release a reader after using it, it will end in excessive
debugging sessions. Further, I personally think that this is not the
'spirit'
of Lucene for this scenario...correct me if I'm wrong ;)
2. Add a finalizer to the reader object and perform a close() there.
References to
reader objects will stay valid. For this, I have to wrap the all Readers
in order
to add the finalize()...the wrap is also not so nice
3. Use the garbage collector for counting the references, and - maybe - use
PhantomReferences to initialize a close process. I don't exactly know
whether
this is possible, because the Phantom reference gets null for its
referent, so
the invocation oof close() seems to be unpossible...
4. Simply don't close the reader Objects, and hope that this is no problem..
To change this hope into knowledge: Is it critical NOT closing an
IndexReader Object
in the case it is used only and entirely read-only? We use the new
IndexWriter
to delete documents in all cases.
If it is critical - is there a common - or uncommon but good - solution for
this, that
I have forgotten?
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
