lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From petite_abeille <>
Subject Re: Index locked for write
Date Mon, 06 Oct 2003 10:06:12 GMT
Hi Dmitry,

On Sunday, Oct 5, 2003, at 22:04 Europe/Amsterdam, Dmitry Serebrennikov 

> 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.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, 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>: Index 
locked for write: 
Lock@/tmp/lucene-5b228139f8fe55f7c74441a7d59f8f89-write.lock Index locked for write: 

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(, anAnalyzer, 
shouldCreate );

This is where the IOException occurs. All the methods are synchronized 
as far as I can tell.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message