Major Description
Here's an example of a seed that currently fails reliably on master...
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)
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.