Hi Otis,
I understand about reusing readers and searchers, but I was working on the "do the simplest thing that can possibly work" theory for starters, in part because I wanted to be sure that I could recreate the index safely as needed.
I should emphasize that I developed for weeks on linux without ever seeing this problem, but in less than 24 hours after installing on the customer's windows box, I hit the error.
So is a close() not really a close()? Is Lucene actually hanging on to open files? Or is this a JVM on windows bug? (I'm using the latest 1.4.2 from Sun.)
As I mentioned, this has turned up off and on in the mail archives. Is there no well-understood fix or work-around? I'll get a stack trace set up for the next time it happens.
Thanks,
Fred
At 08:35 AM 9/20/2004, you wrote:
Fred,
I won't get into the details here, but you shouldn't (have to) open a new IndexReader/Searcher on each request (I'll assume the code below is from your Actions'e xecute method). You should cache and re-use IndexReaders (and IndexSearchers). There may be a FAQ entry regarding that, I'm not sure. Closing them on every request is also something you shouldn't do (opening and closing them is, in simple terms, just doing too much work. Open N files, read them, close them. Open N files, read them, close them. And so on....)
Regarding failing deletion, that's a Windows OS thing - it won't let you remove a file while another process has it open. I am not certain where exactly this error comes from in Lucene (exception stack trace?), but I thought the Lucene code included work-arounds for this.
Otis
--- Fred Toth <[EMAIL PROTECTED]> wrote:
> Hi Sergiu, > > My searches take place in tomcat, in a struts action, in a single > method > Abbreviated code: > > IndexReader reader = null; > IndexSearcher searcher = null; > reader = IndexReader.open(indexName); > searcher = new IndexSearcher(reader); > // code to do a search and extract hits, works fine. > searcher.close(); > reader.close(); > > I have a command-line indexer that is a minor modification of the > IndexHTML.java that comes with Lucene. It does this: > > writer = new IndexWriter(index, new StandardAnalyzer(), > create); > // add docs > > (with the create flag set true). It is here that I get a failure, > "can't > delete _b9.cfs" > or similar. This happens when tomcat is completely idle (we're still > testing and > not live), so all readers and searchers should be closed, as least as > far as > java is concerned. But windows will not allow the indexer to delete > the old > index. > > I restarted tomcat and the problem cleared. It's as if the JVM on > windows > doesn't > get the file closes quite right. > > I've seen numerous references on this list to similar behavior, but > it's > not clear > what the fix might be. > > Many thanks, > > Fred > > At 02:32 AM 9/20/2004, you wrote: > > Hi Fred, > > > >I think that we can help you if you provide us your code, and the > context > >in which it is used. > >we need to see how you open and close the searcher and the reader, > and > >what operations are you doing on index. > > > > All the best, > > > > Sergiu > > > > > > > >Fred Toth wrote: > > > >>Hi, > >> > >>I have built a nice lucene application on linux with no problems, > >>but when I ported to windows for the customer, I started > experiencing > >>problems with the index not closing. This prevents re-indexing. > >> > >>I'm using lucene 1.4.1 under tomcat 5.0.28. > >> > >>My search operation is very simple and works great: > >> > >>create reader > >>create searcher > >>do search > >>extract N docs from hits > >>close searcher > >>close reader > >> > >>However, on several occasions, when trying to re-index, I get > >>"can't delete file" errors from the indexer. I discovered that > restarting > >>tomcat clears the problem. (Note that I'm recreating the index > >>completely, not updating.) > >> > >>I've spent the last couple of hours trolling the archives and I've > >>found numerous references to windows problems with open files. > >> > >>Is there a fix for this? How can I force the files to close? What's > >>the best work-around? > >> > >>Many thanks, > >> > >>Fred > >> > >> > >>--------------------------------------------------------------------- > >>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] > > > > --------------------------------------------------------------------- > 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
