[
https://issues.apache.org/jira/browse/SOLR-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-8135:
---------------------------------
Attachment: SOLR-8135.patch
So far, this patch keeps the test from failing. I hacked this in on the hint
that buried in the failure case was a message about "could not reload core blah
blah blah" and the fact that if I commented out the update config bits the test
succeeded.
Maybe a race condition between multiple API calls modifying the configs and
core reloading? This patch forces the collection to reload as part of updating
the config...
[~noble.paul] [~markrmiller] [[email protected]]
This feels like a band-aid though. I see in the ref guide that listeners are
registered on the zknode and reloads happen sometime although I'm unclear on
what exactly triggers them. It seems like any modification of the config file
should be atomic in the sense that as long as the updates are not invalid, any
core reloads should get a config that doesn't fail to load. How do we guarantee
atomic reads/writes of the config files? Especially when the read path is
different than the write path?
I don't have the logs right now, so I don't have a good sense of what in core
reload was really failing, I'll see if I can get some of that info.
NOTE: I'm on a plane so I could only beast this lightly. Nevertheless, I never
got 4 successful runs before this patch and got 16 with the patch so it
certainly seems in the right neighborhood. I'll be able to give it a more
thorough spin when I'm not on battery. Assuming we think this is the right fix.
> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible
> failure
> ----------------------------------------------------------------------------------
>
> Key: SOLR-8135
> URL: https://issues.apache.org/jira/browse/SOLR-8135
> Project: Solr
> Issue Type: Bug
> Affects Versions: Trunk
> Reporter: Hoss Man
> Attachments: SOLR-8135.failure.log, SOLR-8135.patch
>
>
> No idea what's going on here, noticed it while testing out an unrelated patch
> -- seed reproduces against pristine trunk...
> {noformat}
> [junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=SolrCloudExampleTest
> -Dtests.method=testLoadDocsIntoGettingStartedCollection
> -Dtests.seed=59EA523FFF6CB60F -Dtests.slow=true -Dtests.locale=es_MX
> -Dtests.timezone=Africa/Porto-Novo -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1
> [junit4] FAILURE 49.5s |
> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection <<<
> [junit4] > Throwable #1: java.lang.AssertionError: Delete action failed!
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([59EA523FFF6CB60F:4A896050CE030FA9]:0)
> [junit4] > at
> org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
> [junit4] > at
> org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
> [junit4] > at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
> [junit4] > at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
