[
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
