lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "paul.elschot (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-458) Merging may create duplicates if the JVM crashes half way through
Date Thu, 27 Oct 2005 07:36:58 GMT
    [ http://issues.apache.org/jira/browse/LUCENE-458?page=comments#action_12356051 ] 

paul.elschot commented on LUCENE-458:
-------------------------------------

I don't think that Lucene supports marking a document as in step 3.

In case the concern is that the deleted document would be temporarliy
invisible to searches, it is possible to keep another reader open for searching
while the updates are going on, and this reader will see no changes at all.

Lucene does this by never changing an index segment, it only adds
deletion bits, and these are taken into account when segments are
merged to add docs or to optimize the index. Also, the deletion bits added
by reader B are ignored by reader A when they are not present
when A is opened.
I don't know what happens when a segment has deletion bits when reader A
is opened, and reader B that was opened later deletes more documents.
This situation can be avoided by only deleting documents on optimized indexes.

Anyway, to see the changes after all updates: close the searching reader and
reopen another one to search on the updated index.
Before opening the new reader for searching, but after closing the
last reader/writer that changed the index, there is an opportunity
to sync the disk(s).

Regards,
Paul Elschot


> Merging may create duplicates if the JVM crashes half way through
> -----------------------------------------------------------------
>
>          Key: LUCENE-458
>          URL: http://issues.apache.org/jira/browse/LUCENE-458
>      Project: Lucene - Java
>         Type: Bug
>     Versions: 1.4
>  Environment: Windows XP SP2, JDK 1.5.0_04 (crash occurred in this version.  We've updated
to 1.5.0_05 since, but discovered this issue with an older text index since.)
>     Reporter: Trejkaz

>
> In the past, our indexing process crashed due to a Hotspot compiler bug on SMP systems
(although it could happen with any bad native code.)  Everything picked up and appeared to
work, but now that it's a month later I've discovered an oddity in the text index.
> We have two documents which are identical in the text index.  I know we only stored it
once for two reasons.  First, we store the MD5 of every document into the hash and the MD5s
were the same.  Second, we store a GUID into each document which is generated uniquely for
each document.  The GUID and the MD5 hash on these two documents, as well as all other fields,
is exactly the same.
> My conclusion is that a merge was occurring at the point the JVM crashed, which is consistent
with the time the process crashed.  Is it possible that Lucene did the copy of this document
to the new location, and didn't get to delete the original?
> If so, I guess this issue should be prevented somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message