[
https://issues.apache.org/jira/browse/SOLR-9836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16099049#comment-16099049
]
Steve Rowe commented on SOLR-9836:
----------------------------------
Non-reproducing master failure from my Jenkins yesterday:
{noformat}
Checking out Revision 97ca529e49505cef0c1dd6138ed70be4a7b85610
(refs/remotes/origin/master)
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=MissingSegmentRecoveryTest -Dtests.method=testLeaderRecovery
-Dtests.seed=E0C710C4147CEA7B -Dtests.multiplier=2 -Dtests.nightly=true
-Dtests.slow=true
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt
-Dtests.locale=ar-BH -Dtests.timezone=Asia/Urumqi -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] FAILURE 95.9s J2 | MissingSegmentRecoveryTest.testLeaderRecovery <<<
[junit4] > Throwable #1: java.lang.AssertionError: Expected a collection
with one shard and two replicas
[junit4] > null
[junit4] > Live Nodes: [127.0.0.1:42849_solr, 127.0.0.1:43941_solr]
[junit4] > Last available state:
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/9)={
[junit4] > "pullReplicas":"0",
[junit4] > "replicationFactor":"2",
[junit4] > "shards":{"shard1":{
[junit4] > "range":"80000000-7fffffff",
[junit4] > "state":"active",
[junit4] > "replicas":{
[junit4] > "core_node1":{
[junit4] >
"core":"MissingSegmentRecoveryTest_shard1_replica_n1",
[junit4] > "base_url":"https://127.0.0.1:42849/solr";,
[junit4] > "node_name":"127.0.0.1:42849_solr",
[junit4] > "state":"active",
[junit4] > "type":"NRT",
[junit4] > "leader":"true"},
[junit4] > "core_node2":{
[junit4] >
"core":"MissingSegmentRecoveryTest_shard1_replica_n2",
[junit4] > "base_url":"https://127.0.0.1:43941/solr";,
[junit4] > "node_name":"127.0.0.1:43941_solr",
[junit4] > "state":"down",
[junit4] > "type":"NRT"}}}},
[junit4] > "router":{"name":"compositeId"},
[junit4] > "maxShardsPerNode":"1",
[junit4] > "autoAddReplicas":"false",
[junit4] > "nrtReplicas":"2",
[junit4] > "tlogReplicas":"0"}
[junit4] > at
__randomizedtesting.SeedInfo.seed([E0C710C4147CEA7B:B09288C74D5D5C66]:0)
[junit4] > at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
[junit4] > at
org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery(MissingSegmentRecoveryTest.java:105)
[...]
[junit4] 2> NOTE: test params are:
codec=HighCompressionCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=HIGH_COMPRESSION,
chunkSize=4, maxDocsPerChunk=1, blockSize=790),
termVectorsFormat=CompressingTermVectorsFormat(compressionMode=HIGH_COMPRESSION,
chunkSize=4, blockSize=790)), sim=RandomSimilarity(queryNorm=true): {},
locale=ar-BH, timezone=Asia/Urumqi
[junit4] 2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation
1.8.0_77 (64-bit)/cpus=16,threads=1,free=300978976,total=530055168
[junit4] 2> NOTE: All tests run in this JVM: [SolrCloudReportersTest,
TestConfigSetsAPIExclusivity, TestCloudJSONFacetJoinDomain,
RequestHandlersTest, TestRangeQuery, TestJsonFacetRefinement, ZkCLITest,
ExternalFileFieldSortTest, LukeRequestHandlerTest, SimpleMLTQParserTest,
AutoScalingHandlerTest, CdcrBootstrapTest, TestBulkSchemaConcurrent,
CoreAdminHandlerTest, SuggestComponentTest, TestRuleBasedAuthorizationPlugin,
CdcrUpdateLogTest, SpellCheckCollatorWithCollapseTest, SortByFunctionTest,
MissingSegmentRecoveryTest]
{noformat}
> 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
> Assignee: Mark Miller
> Fix For: 7.0, 6.7
>
> Attachments: SOLR-9836.patch, SOLR-9836.patch, SOLR-9836.patch,
> SOLR-9836.patch, 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.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
