[
https://issues.apache.org/jira/browse/SOLR-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16765440#comment-16765440
]
Hoss Man commented on SOLR-13237:
---------------------------------
IIUC that's a different situation: SOLR-13193 is about the "mock corruption"
layer code in LeaderTragicEventTest not recognizing the possibility of a
NoSuchFileException when it was introducing corruption (which is possible if
the file it's trying to corrupt gets merged away).
The issue here / in LUCENE-8692 is that the "attempt to use files" code in the
actual IndexWriter (or underlying "real" code IndexWriter delegates to) isn't
accounting for NoSuchFileExceptions as being "tragic"
> Not al types of index corruption garuntee a leader will "give up its
> leadership"
> --------------------------------------------------------------------------------
>
> Key: SOLR-13237
> URL: https://issues.apache.org/jira/browse/SOLR-13237
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Priority: Major
> Attachments: SOLR-13237_logging.patch, log-fail-5D803D4699663918.txt,
> log-fail-DEADBEEF.txt, log-pass-BEEFBEEF.txt, log-pass-FEEDBEEF.txt
>
>
> While investigating failures from LeaderTragicEventTest, I've found some
> reproducible situations where (externally introduced) index corruption can
> cause a leader to reject updates, but not automatically give up it's
> leadership.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
