I suspect what happened is result of a "mis-ordered" upgrade sequence:
The first of the two applications managed to access and upgrade
the index. However the second application then tried to update the
already upgraded index and messed things up.
I think this may even be worse, as one of the changes since 2.0 is
that write locks are now (by default) maintained in the index directory.
So if the two applications attempt to access the index at the same time,
but one uses 2.0 and the other uses "to-be-2.1" version, since locks
are maintained in different places, they might both write to the index
at the same time and corrupt it.
A related discussion is in this thread:
http://issues.apache.org/jira/browse/LUCENE-771#action_12464409
To conclude, the upgrade steps should be:
1) upgrade all readers.
2) upgrade all writers at once (no old writer should access the
index ones this step started).
Regards,
Doron
"Van Nguyen" <vnguyen@ur.com> wrote on 12/02/2007 16:55:59:
I have two applications that share some of the same Lucene Indexes. I
recently upgrade the Lucene-core.jar from v2.0 to a nightly build (Feb.
04, 2006 - I was looking for the IndexWriter class that allows you to
merge indexes w/o optimizing).
Now I notice the index is a little different:
Prior to upgrading:
_0.cfs
deletable
segments
After upgrading:
_g.cfs
segments.gen
segments_17
Didn't think much of it until I started my test server and things
stopped working. I started debugging, and it seems like the
Lucene-core.jar (the version that was not built on Feb. 04, 2006) looks
at the new index and thinks that it does not exist... so it tries to
create a new index. It is successful at deleting the .cfs file, but not
the .gen and segments_17 (I'm assuming it doesn't recognize those types
of file).
Has anyone else run into this problem?
recently upgrade the Lucene-core.jar from v2.0 to a nightly build (Feb.
04, 2006 - I was looking for the IndexWriter class that allows you to
merge indexes w/o optimizing).
Now I notice the index is a little different:
Prior to upgrading:
_0.cfs
deletable
segments
After upgrading:
_g.cfs
segments.gen
segments_17
Didn't think much of it until I started my test server and things
stopped working. I started debugging, and it seems like the
Lucene-core.jar (the version that was not built on Feb. 04, 2006) looks
at the new index and thinks that it does not exist... so it tries to
create a new index. It is successful at deleting the .cfs file, but not
the .gen and segments_17 (I'm assuming it doesn't recognize those types
of file).
Has anyone else run into this problem?
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
