lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hani Suleiman <>
Subject Re: Compound file index issue
Date Thu, 15 Jan 2004 18:30:28 GMT
Bruce, the lockfiles being left over previously was due to the bad file 
locking (the timestamp bug) which would occur fairly frequently on 
linux, so I'd say you should enable that as the root cause has been fixed.

Bruce Ritchie wrote:

> Doug Cutting wrote:
>>> We did disable lucene's file based locking mechanism since our app is 
>>> not setup to allow multiple different JVM's to write to a single 
>>> index (one index per JVM) and we've had no end of issues with the 
>>> file based locking. This was done by just setting 
>>> FSDirectory.DISABLE_LOCKS to true;
>> Are you reading the index from multiple JVMs?  If so, you still need 
>> the lock files.  Lock files can be disabled only (a) if the index is 
>> never modified; or (b) if it is only accessed from a single JVM.  The 
>> latter case is probably not tested much, and I don't see any reason to 
>> rely on it.
> No, we never allow multiple JVM's to access a single index. Rather, each 
> server (and thus each JVM) has it's own lucene index that it manages. 
> Any customer that tries to run multiple JVM's accessing a single 
> jiveHome (which contains all of Jive's configuration along with the 
> search index) will have many more issues than just lucene.
>> Why are you disabling lock files anyway?  Did you have problems with 
>> them?  They don't have a performance impact, and serve to protect you 
>> from problems like this.
> We've had many customers issues logged with "leftover" lock files 
> causing search indexing to stop working. This may be related to 
> application server restarts however it did seem to occur sometimes even 
> when the application server has not restarted. Almost as if 
> file.delete() did not always work. Since we didn't need the 
> functionality provided by the lock files, we just configued lucene to 
> not use them.
> Regards,
> Bruce Ritchie

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

View raw message