[ https://issues.apache.org/jira/browse/SOLR-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672035#comment-16672035 ]
Hoss Man commented on SOLR-7804: -------------------------------- Ok ... so here's what's happening in both the seed sarowe mentioned, (and I believe the failure shalin mentioned a year ago that i didn't notice at the time)... When I wrote this test way way back, I knew & recognized that when dealing with floating point values, the order that the docs were collected in a shard, and the intermediate stats (sum & sumOfSquares) were accumulated from multiple shards, could intoduce subtle variations in the final values – the classic "due to precision loss, the _order_ of a sequence of additions of flots|doubles matters" I even tried to be smart, and wrote the test to expect a bit of epsillon when looking at stats on Doubles and Floats. What I forgot at the time was that when computing stats for *Date* fields, floating point intermediate values are used (because the sum|sumOfSquares for a lot of big longs can easily overflow a long) ... so while the final "mean" value may be a Date object, the "millisSinceEpoch" used to build that date comes from a {{(long)(((double)sum)/((long)count))}} I also didn't account for the fact that my "pick an epsilon based on the magnitude of the expected value" wasn't going to work well when the expected value is "0.0". ---- I could update the test to make the Date comparisons also use an epsilon and be lossy to account for hte intermediate floating point math, and update the epsilon calculation for things like stddev to be based on the min/max ... but ultimatley i think we should just completely remove the checks of lossy stats .... This test really isn't about stats. It tries to verify that stats computed on pivot facet buckets match equivilent stats for queries against those bucket constraints because it wants to ensure the delegation of pivot faceting to stats works – but this same type of subtle inconsistentcies that cause these failures can exist if you just did a top level stats request against a query (w/o using faceting) over and over and get differnet replica orders on the distributed merge. So i think what makes sense is to simplify the test and only bother collecting the basic stats that should *never* be lossy (count, missing, min, max) regardless of field type, and disable the other stats. that will give us plenty of sanity checking that hanging stats on pivots works correctly. I'll work this up, hammer on it, and commit ASAP. > TestCloudPivotFacet failures: expected:<X> but was:<Y> > ------------------------------------------------------ > > Key: SOLR-7804 > URL: https://issues.apache.org/jira/browse/SOLR-7804 > Project: Solr > Issue Type: Bug > Components: faceting > Affects Versions: 5.3, 6.0 > Reporter: Steve Rowe > Assignee: Hoss Man > Priority: Major > > A couple failures recently on my Jenkins (Linux), both on branch_5x and trunk > - here's one on trunk: > [http://jenkins.sarowe.net/job/Lucene-Solr-tests-trunk/766/], and another on > branch_5x: [http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/546/]. > I reproduced another branch_5x failure from a few days ago (Jenkins job has > been removed already) on OS X, using both java7 and java8: > {noformat} > [junit4] 2> NOTE: reproduce with: ant test > -Dtestcase=TestCloudPivotFacet -Dtests.method=test > -Dtests.seed=D8E5204E25B3DB16 -Dtests.slow=true -Dtests.locale=es_PA > -Dtests.timezone=America/El_Salvador -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 > [junit4] FAILURE 46.6s | TestCloudPivotFacet.test <<< > [junit4] > Throwable #1: java.lang.AssertionError: > {main(facet=true&facet.pivot=%7B%21stats%3Dst0%7Dpivot_ti1&facet.pivot=%7B%21stats%3Dst0%7Dpivot_ti1&facet.limit=4&facet.offset=6&facet.missing=true&facet.overrequest.ratio=-0.9744149),extra(rows=0&q=id%3A%5B*+TO+448%5D&fq=id%3A%5B*+TO+516%5D&_test_miss=true)} > num pivots expected:<2> but was:<1> > [junit4] > at > __randomizedtesting.SeedInfo.seed([D8E5204E25B3DB16:50B11F948B4FB6EE]:0) > [junit4] > at > org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:251) > [junit4] > at > org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:228) > [junit4] > at > org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) > [junit4] > at > org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) > [junit4] > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org