Major Description
while helping to run tests on a feature branch, sarowe found this failure...
[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=SegmentsInfoRequestHandlerTest -Dtests.method=testSegmentInfosData -Dtests.seed=5BB5CF0D868944FB -Dtests.slow=true -Dtests.locale=zh-CN -Dtests.timezone=Pacific/Samoa -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] ERROR 0.12s J11 | SegmentsInfoRequestHandlerTest.testSegmentInfosData <<< [junit4] > Throwable #1: java.lang.RuntimeException: Exception during query [junit4] > at __randomizedtesting.SeedInfo.seed([5BB5CF0D868944FB:271CED563061F364]:0) [junit4] > at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:821) [junit4] > at org.apache.solr.handler.admin.SegmentsInfoRequestHandlerTest.testSegmentInfosData(SegmentsInfoRequestHandlerTest.java:71) [junit4] > at java.lang.Thread.run(Thread.java:745) [junit4] > Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=10=sum(//lst[@name='segments']/lst/int[@name='size']) [junit4] > xml response was: <?xml version="1.0" encoding="UTF-8"?> [junit4] > <response> [junit4] > <lst name="responseHeader"><int name="status">0</int><int name="QTime">0</int></lst><lst name="segments"><lst name="_4"><str name="name">_4</str><int name="delCount">5</int><long name="sizeInBytes">1995</long><int name="size">9</int><date name="age">2017-01-16T06:10:10.308Z</date><str name="source">merge</str><str name="version">7.0.0</str><bool name="mergeCandidate">true</bool></lst><lst name="_5"><str name="name">_5</str><int name="delCount">0</int><long name="sizeInBytes">1562</long><int name="size">5</int><date name="age">2017-01-16T06:10:10.341Z</date><str name="source">flush</str><str name="version">7.0.0</str><bool name="mergeCandidate">true</bool></lst></lst> [junit4] > </response>
...this failure reproduces (on master at least), but only if you remove the -Dtests.method=testSegmentInfosData restriction so that all tests run.
At quick glance, it's pretty obvious this test doesn't do proper cleanup between methods before rebuilding the index (AFAICT there's no reason not to just build the index once in @BeforeClass) and that seems to be leading to failures if the methods are executed in a particular order such that the method counting total docs/deletes in all segments runs after enough docs have been added to trigger a merge. (pretty sure we also need to force the merge policy settings to ensure it doesn't randomly merge)