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]
