You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2017/01/18 00:38:27 UTC
[jira] [Resolved] (SOLR-9977) reproducible failures in
DistribDocExpirationUpdateProcessorTest due to IndexWriterConfig
randomization
[ https://issues.apache.org/jira/browse/SOLR-9977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man resolved SOLR-9977.
----------------------------
Resolution: Fixed
Fix Version/s: 6.5
master (7.0)
> reproducible failures in DistribDocExpirationUpdateProcessorTest due to IndexWriterConfig randomization
> -------------------------------------------------------------------------------------------------------
>
> Key: SOLR-9977
> URL: https://issues.apache.org/jira/browse/SOLR-9977
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Assignee: Hoss Man
> Fix For: master (7.0), 6.5
>
>
> Here's an example of a seed that currently fails reliably on master...
> {noformat}
> ant test -Dtestcase=DistribDocExpirationUpdateProcessorTest -Dtests.method=test -Dtests.seed=34988FCF7C369D9 -Dtests.slow=true -Dtests.locale=el -Dtests.timezone=Etc/GMT+10 -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> [junit4] > Throwable #1: java.lang.AssertionError: Exactly one shard should have changed, instead: [core_node1, core_node2] nodes=([expiry_shard2_replica1(core_node1), expiry_shard1_replica1(core_node2)]) expected:<1> but was:<2>
> [junit4] > at __randomizedtesting.SeedInfo.seed([34988FCF7C369D9:8B1DB726593F0421]:0)
> [junit4] > at org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.test(DistribDocExpirationUpdateProcessorTest.java:116)
> {noformat}
> The meat of the test is to verify that the periodic DBQs triggered by the DocExpirationUpdateProcessor don't cause unnecessary new searchers w/cache flushing/warming. -- only shards affected by deltheetes get their searchers re-opened.
> enabling infoStream logging on the test shows that (something I havne't fully dug into in) the randomized IndexWriterConfig is causing the IndexWriter to generate a new segments file after a commit early in the test -- completely unrelated to the DBQ+commit logic we're paying close attention to -- that still contains the exact same underlying segments/docs. It's just a new segments file name with a new index version# -- which throws off the index version# tracking the test is using to make sure only the segment that should be impacted by our DBQ is impacted by the DBQ.
> ----
> Since this kind of randomized index changing under the covers contradicts the methodology used in the test, it should be removed so we can reliably know that the only reason an reader/searcher changes is either because the solr code being tested does it deliberately, or because of a bug that needs fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org