lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nader Henein <>
Subject Re: commit lock, graceful handler
Date Tue, 02 Nov 2004 09:58:06 GMT
Graceful, no, I started a discussion on this about two years ago, what 
I'm doing is a batched indexing so if a crash occurs the next time the 
application starts up I have an  LuceneInit class that goes and ensures 
that all indecies have no locks on them by simply deleting the lock file 
and optimizing the index, this has worked for us well for the past two 
years in a production environment and the next indexing run will pick up 
the same batch and re-index it, which doesn't hurt the index because 
every time I add a document to the index, I actually delete it first to 
ensure that there are no repetitions, we've never had an index go 
corrupt on us but we do have six indecies being updated in parallel in 
addition to nightly backups by our hosting facility during a one hour 
window where we do no updates/deletes on the index to ensure that the 
backup is kosher.

It may not be graceful as Oracle Rollback Tables but it's functional and 
a lot less complicated.


Jackson Earnst wrote:

>I'm testing fault tollerance aspects of an application using Lucene. 
>Consider if power is pulled form the server/workstation and it
>immediately shuts down hard or crashes.
>I'm faced with a situation of a commit.lock file exising in the temp
>directory.  Lucene is throwing an exception when a writer is first
>created against this index.  An IOexception comes about and "Lock
>obtained timed out" error occurs.
>REading some docs anf FAQs I see that this could be deleted and the
>index will be in a usable state.
>Any advice/comments/thoughts?
>Is there a graceful way to handle this?  
>To unsubscribe, e-mail:
>For additional commands, e-mail:

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

View raw message