[
https://issues.apache.org/jira/browse/LUCENE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633096#action_12633096
]
Uwe Schindler commented on LUCENE-1385:
---------------------------------------
bq. Is it possible that your indexing job that wakes up and only makes calls to
deleteDocuments yet no documents matched the deleted terms?
I looked into the logs of the indexer: It is doing exactly this. It gets
information to delete documents (from an Open Archives Protocol Harvester), but
the documents were not in the index. And it does not add new documents, so you
are correct.
It should not happen that the index version changes when no changes (no-op
deletes) were done. This is happening rather often in my code. reopen() should
check this or better IndexWriter should not change the index version on no-ops.
Currently I am working on code for the new features in 2.4 and will soon try
2.4 for my project. If LUCENE-1194 solves this, should we then close the bug
after I tested my code with 2.4?
> IndexReader.isIndexCurrent()==false -> IndexReader.reopen() -> still index
> not current
> --------------------------------------------------------------------------------------
>
> Key: LUCENE-1385
> URL: https://issues.apache.org/jira/browse/LUCENE-1385
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Affects Versions: 2.3.2
> Environment: Linux, Solaris, Windows XP
> Reporter: Uwe Schindler
> Attachments: LUCENE-1385.patch
>
>
> I found a strange error occurring with IndexReader.reopen. It is not always
> reproduceable, it only happens sometimes, but strangely on all my computers
> with different platforms at the same time. Maybe has something to to with the
> timestamp used in index versions.
> I have a search server using an IndexReader, that is openend in webapp
> startup and should stay open. Every half an hour this web application checks,
> if the index is still current using IndexReader.isCurrent(). When a parallel
> job that indexes documents (in another virtual machine) and modifies the
> indexes, isCurrent() return TRUE. The half-hourly cron-job then uses
> IndexReader.reopen() to reopen the index. But sometimes, directly after
> reopen() the Index is still not current (and no updates occur). Again calling
> reopen does not change it, too. Searching on the index shows all new/updated
> documents, but isCurrent() still return false. The problem with this is, that
> now the index is reopened all the time, because the detection of a current
> index does not work any more.
> I have now a workaround in my code to handle this: After calling
> IndexReader.reopen(), I test for IndexReader.isCurrent(), and if not, I close
> it hard and open a new instance.
> Most times IndexReader.reopen works correct, but sometimes this error occurs.
> Looking into the code of reopen(), I realized, that there is some extra
> check, if the Index has modifications, and if yes the reopen call returns the
> original reader (this maybe the problem I have). But the IndexReader is only
> used for searching, no updates occur.
> My questions: Why is there this check for modifications in reopen()? Why does
> this happen only at certain times on all my servers with different platforms?
> I want to use reopen, because in future, when the new FieldCache will be
> reopen-aware and does not everytime rebuild the full cache, it will be very
> important, to have this fixed. At the moment, I have no problem with the
> case, that reopen may fail and I have to do a rough reopen.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
