[
https://issues.apache.org/jira/browse/SOLR-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16785953#comment-16785953
]
Hoss Man commented on SOLR-13237:
---------------------------------
I've updated the issue summary with some notes regarding the discussion in
LUCENE-8692.
I think ultimately we're going to need to reconsider & broaden the criteria for
when a node gives up it's leadership to be more aggressive then just a simple
check for of {{IW.getTragicException()}} ... but i'm not sure what that should
look like.
In the mean time, i'm going to disable LeaderTragicEventTest as it's unreliable.
> 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.
> See discussion in LUCENE-8692 – notably simon's comment on why/how some
> things are explicitly not treated as tragic today for a disucssion of the
> root cause.
> *We may need/want to rethink & improve the situations where a leader gives up
> leadership, above and beyond IW registering a tragic exception*
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
