Hoss Man created SOLR-9977:
------------------------------
Summary: 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
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
