[ https://issues.apache.org/jira/browse/SOLR-9836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Drob updated SOLR-9836: ---------------------------- Attachment: SOLR-9836.patch bq. I believe it's in SegmentInfos->FindSegmentsFile That only goes forward in case of concurrent commits, I don't see it ever falling back to an older segments. Changes in latest patch: * Completely drop attempts to open older segments. Leaving it for future work. * Added javadocs. * Preserve original exception in case there is still a problem the second time we create SolrCore {{MissingSegmentRecoveryTest}} takes ~45 seconds to run on my machine. Is this long enough that it deserves a {{@Slow}} annotation? > Add more graceful recovery steps when failing to create SolrCore > ---------------------------------------------------------------- > > Key: SOLR-9836 > URL: https://issues.apache.org/jira/browse/SOLR-9836 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud > Reporter: Mike Drob > Attachments: SOLR-9836.patch, SOLR-9836.patch, SOLR-9836.patch > > > I have seen several cases where there is a zero-length segments_n file. We > haven't identified the root cause of these issues (possibly a poorly timed > crash during replication?) but if there is another node available then Solr > should be able to recover from this situation. Currently, we log and give up > on loading that core, leaving the user to manually intervene. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org