[
https://issues.apache.org/jira/browse/SOLR-9977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15878514#comment-15878514
]
ASF subversion and git services commented on SOLR-9977:
-------------------------------------------------------
Commit c58eac13378f618532190348574d96a72ef413e7 in lucene-solr's branch
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c58eac1 ]
SOLR-9977, SOLR-9979: move CHANGES entries to correct section (Bug)
Aparently these were shifted during merge/cherry-picks
> 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: 6.5, master (7.0)
>
>
> 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.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
