[ 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org