Thanks for your response. Is there a way that I can disable these read 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.
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). 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?). thanks Nilesh On 3/31/07, Michael McCandless <[EMAIL PROTECTED]> wrote:
"Nilesh Bansal" <[EMAIL PROTECTED]> wrote: > We have a web-based application that searches a large lucene index. > This application only creates object of type IndexSearcher only (and > no IndexWriters) for searching the index. After the application runs > for some time (a few hours), I can see lock files in the temp > directory of the form > /opt/tomcat/temp/lucene-5f77ffdc821b3f8e861949e9ecc35a53-commit.lock > The temp dir is set to /opt/tomcat/temp/ as we are using tomcat. > > Since the application is read-only, there is no point in it using the > lock files. These lock files are creating a lot of trouble for me, as > their presence leads to a lock obtained timeout in other threads. It > seems like a bug in lucene. > > The index is updated be a separate process independent of the > web-application once in a while. Currently I am using an independent > shell script that checks for the temp dir for lock files every few > seconds and deletes the lock files if any (to prevent a lock obtained > timeout in other threads). The commit lock has been problematic in the past and has been removed entirely (so readers are indeed read only) as of release 2.1. Before 2.1, it is very necessary: a reader acquires this lock (creates the file) when it's reading the segments file, to prevent a writer from overwriting the file at the same time. Likewise a writer acquires this lock before overwriting the segments file. However it should exist only briefly, so the fact that you see the lockfile staying around means something bad is happening. Do you ever see the JVM crash? Or any errant exceptions from your readers? These could cause the lock file to be incorrectly left in the filesystem. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Nilesh Bansal. http://queens.db.toronto.edu/~nilesh/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
