On Sunday, Oct 5, 2003, at 22:04 Europe/Amsterdam, Dmitry Serebrennikov wrote:
No one seems to have responded to this yet, so I'll give a first shot.
Thanks :)
There were a few changes that I am aware of that occured in the locking area. One of Lucene's locking rules is that IndexWriter cannot co-exist with an "deleting" IndexReader. An IndexReader becomes "deleting" when delete method is called on it. If one of these exists, trying to open the other one will cause the exception you are observing (I believe). The changes in this area were in tightening the logic enforcing this rule.
Hmmmm... interesting... in my case I do make sure to close any potential IndexReader before processing a IndexWriter. Here is the relevant code:
this.invalidateReader();
this.writer().addIndexes( new Directory[] { aDirectory } );This chunk of code is synchronized as are all the other methods which interact directly with Lucene. The invalidateReader() method is called to ensure that any existing IndexReader are closed before invoking addIndexes(). So in theory, there should be only one IndexWriter active when this method is called.
There were a couple of test cases submitted, TestIndexReader.java I believe, that illustrated two conditions that were not handled properly in the old code. They are now handled correctly, but there is still an open issue regarding the timestamp resolution in Mac OSX that uses an older filesytem (I'm not a Mac user myself, so I don't know what that file system is called). Apparently that filesystem can only resolve timestamps up to a second, so the locking logic, which is based on the file timestamps, can fail. The same failure can (and does) also occur on other filesystems, but it would occur on Mac more often. Again, try the test case. Apparently one of the two test cases still fails on Mac OSX.
How is the lock deletion handled? Would it be possible for a lock to become "stall" for a little while after it was deleted, but perhaps before the filesystem properly reflect the deletion?
If you search for Mac in the last week of the traffic on this list you will find more information about this issue and some suggested fixes. There was also a discussion about which of the multiple proposed evils would be better, but there is still no resolution to this issue.
Can I turn off the file locking altogether? :) In my case, I really don't need such complication as my indices are solemnly accessed by only one application.
Good luck.
Thanks, I need it :)
P.S.: it might be helpful if you include a more complete stack trace of the exception you are seeng, such that it would show what operations are being attempted when the failure occurs.
Ok, here is the complete trace:
10/04 10:31:32 (Warning) IndexWriter.<init>: java.io.IOException: Index locked for write: Lock@/tmp/lucene-5b228139f8fe55f7c74441a7d59f8f89-write.lock
java.io.IOException: Index locked for write: Lock@/tmp/lucene-5b228139f8fe55f7c74441a7d59f8f89-write.lock
at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:173)
at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:150)
at alt.dev.szobject.SZIndex.writer(SZIndex.java:582)
at alt.dev.szobject.SZIndex.flush(SZIndex.java:544)
at alt.dev.szobject.SZIndex.optimize(SZIndex.java:335)
at alt.dev.szobject.SZIndexer.optimize(SZIndexer.java:325)
at alt.dev.szobject.SZStore.saveChanges(SZStore.java:661)
at alt.dev.szmail.SZMailProcessor.run(SZMailProcessor.java:293)
at java.lang.Thread.run(Thread.java:554)
The entry method is SZStore.saveChanges() which basically flush any persistent data to disk. There is one SZStore per user. And one SZIndexer per store. There are as many SZIndex as persistent classes. But only one SZIndex per class, per indexer. SZIndex is the only class dealing with Lucene indices directly. Specifically, SZIndex.flush() will add a RAMDirectory to a FSDirectory using IndexWriter.addIndexes(). SZIndex.writer() is the method which build an appropriate IndexWriter:
_writer = new IndexWriter( this.directory().getPath(), anAnalyzer, shouldCreate );
This is where the IOException occurs. All the methods are synchronized as far as I can tell.
Cheers,
PA.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
