: locks without upgrading to 2.1. Our application uses its own custom : locking mechanism, so that lucene locking is actually redundant. We : are currently using Lucene version 2.0.
since before the 2.0.0 release there has been a static FSDirectory.setDisableLocks that can be called before opening any indexes to prevent locking -- it's only intended to be used on indexes on read only disk -- which is not the case in your situation, since a seperate process is in fact modifying the index, but if you are confident in your own locking mechanism you can use it. : The application has multiple threads (different web requests) reading : the same index simultaneously (say 20 concurrent threads). Can that be : a reason of this problem. Sometimes the lockfiles remain there for : long periods of time (more than a few minutes, which is bad). mutliple reader threads should not cause the commit lock to stay arround that long, even if each thread is opening it's on IndexReader (which they should not do, it's better to open one and reuse it among many threads) : Yes, JVM sometimes crashes when it runs out of memory. There should be : someway that the lock files are removed after such crash (any fixes is : 2.1?). As Michael said, in 2.1 the commit lock doesn't even exist, and in general there is a much more robust lock management system that lets you decide what type of lock mechanism to use. in 2.0.0 your only option for dealing with stale locks is to forcebly remove them, but there is a handy static IndexReader.unlock method for doing just that. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
