[
https://issues.apache.org/jira/browse/SOLR-9977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15827138#comment-15827138
]
ASF subversion and git services commented on SOLR-9977:
-------------------------------------------------------
Commit 9ee48aa857e15461dd6ec6482194141da72e0ba2 in lucene-solr's branch
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9ee48aa ]
SOLR-9977: Fix config bug in DistribDocExpirationUpdateProcessorTest that
allowed false assumptions about when index version changes
> 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: [email protected]
For additional commands, e-mail: [email protected]
