lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nader S. Henein" <>
Subject RE: Crash / Recovery Scenario
Date Tue, 09 Jul 2002 04:53:47 GMT
I understand that these files are there for a reason but in case of a web
server crash
lucene will not be able to update/delete/optimize the index in the existence
of these files,
the existence of these two files after a web server restart means that the
crash occurred when
the web server was editing the index and since there is no way to Rollback
(is there?, that would be a cool feature) I have to cut my losses and

Sorry for thinking out loud but speaking of rollback, I asked a question a
while back about
backing up the index while it's being written to.
and Peter told me that it's no problem especially on a Unix machine because
the Lucene writer creates a new index and
only deletes the old one while it's working on the new one, so is there a
way of checking for the .lock files in case
of a crash a rolling back to the old index image?

Nader Henein

-----Original Message-----
From: Otis Gospodnetic []
Sent: Monday, July 08, 2002 9:43 PM
To: Lucene Users List;
Subject: Re: Crash / Recovery Scenario


I don't have a solution for you, but just removing these two files is
probabl not a good idea.  There is a reason for their existence.
Actually, check jGuru Lucene FAQ for more information about them.

s/witch/which/gi :)
witch = the ugly woman flying around on a broom stick :)

--- "Nader S. Henein" <> wrote:
> I'm currently using Lucene to sift through about a million documents,
> I've
> written a servlet to do the indexing and the searching, the servlets
> are ran
> through resin, The Crash scenario I'm thinking of is a web server
> crash (
> for a million possible reasons ) while the index is being updated or
> optimized, what I've noticed is the creation of write.lock and
> commit.lock
> files witch stop further indexing because the application thinks that
> the
> previously scheduled indexer is still running (witch could very well
> be true
> depending on the size of the update). This is the recovery I have in
> mind
> but I think it might be somewhat of a hack, On restart of the web
> server
> I've written an Init function that checks for write.lock or
> commit.lock ,
> and if either exist it deletes both of them and optimizes the index.
> Am I
> forgetting anything ? is this wrong ? is there a Lucene specific way
> of
> doing this like running the optimizer with a specific setup.
> Nader S. Henein
> , Dubai Internet City
> Tel. +9714 3911900
> Fax. +9714 3911915
> GSM. +9715 05659557
> --
> To unsubscribe, e-mail:
> <>
> For additional commands, e-mail:
> <>

Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free

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

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

View raw message