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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to