I agree with Chris's assessment, and so I'm not tallying the vote...
On Fri, Apr 26, 2024 at 1:49 PM Chris Hostetter <hossman_luc...@fucit.org>
wrote:
>
> : Reproduced on my machine too, but it's a timeAllowed test that relies on
> : timeAllowed=0 which is arguably a degenerate setting, OTOH it did start
> : failing in march, and timeAllowed/Limits are something touched in this
> : release.
>
> TL;DR: This is just a blatently bad test, and doesn't seem to indicate any
> sort of regression. I don't think this failure should block the
> release.
>
>
>
> Adding some debug logging to the test shows that the reason this seed can
> reproduce (on a fast machine) is because of the q param produced by this
> seed...
>
> q=int_id: [0 TO 21] AND long_ld: [0 TO 0]
>
>
> ..."0" is not a value that is ever indexed in the "long_ld" field in any
> document -- the indexing code uses it as a sentinal value to mean "skip
> this field for this doc" ...
>
> if (l != 0l) {
> fields.add("long_ld");
> fields.add("" + l);
> fields.add("long_ldm");
> fields.add("" + l);
> }
>
> ... so this query (with his seed) is garunteed to not to match any docs,
> which means the TimeLimitingBulkScorer.INTERVAL is never going to be
> exceeded by any code inside the IndexSearcher.
>
> The analytics component itself seems to depend on ExitableDirectoryReader
> to enforce anything timeAllowed related -- but that hasn't been used by
> default since SOLR-16693 (and the abalytics component tests don't set the
> sysprop to force it to be used)
>
>
> So...
>
> 1) timeAllowed=0 (a pathalogically non-sense input) sometimes doesn't
> trigger partialResults in SolrIndexSearcher when the query matchines no
> documents.
>
> ... shouldn't be a 9.6 release blocker IMO
>
> 2) AnalyticsHandler specific code hasn't respected timeAllowed (or any of
> the other new query limits)
> by default since Solr 9.3
>
> ... shouldn't be a 9.6 release blocker by any objectve standard
>
>
>
>
>
>
> :
> :
> https://ge.apache.org/scans/tests?search.relativeStartTime=P90D&search.rootProjectNames=solr-root&search.timeZoneId=America%2FNew_York&tests.container=org.apache.solr.analytics.legacy.facet.LegacyFieldFacetTest&tests.test=timeAllowedTest
> :
> : History on fucit however shows that it did have a spate of failures last
> : spring too:
> :
> :
> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.analytics.legacy.facet.LegacyFieldFacetTest.timeAllowedTest
> :
> :
> : On Fri, Apr 26, 2024 at 9:31 AM Michael Gibney <
> mich...@michaelgibney.net>
> : wrote:
> :
> : > I got a test failure that reproduces for me locally:
> : >
> : > gradlew :solr:modules:analytics:test --tests
> : >
> : >
> "org.apache.solr.analytics.legacy.facet.LegacyFieldFacetTest.timeAllowedTest"
> : > -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1
> : > -XX:+UseParallelGC -XX:ActiveProcessorCount=1
> : > -XX:ReservedCodeCacheSize=120m" -Ptests.seed=F36DBDF5646C7DC2
> : > -Ptests.badapples=false -Ptests.file.encoding=UTF-8
> : >
> : > On Thu, Apr 25, 2024 at 11:46 PM David Smiley <dsmi...@apache.org>
> wrote:
> : > >
> : > > False alarm; it's a test bug that randomly re-orders docs at merge.
> : > > I'll file a PR in a bit.
> : > >
> : > > +1 vote for the release.
> : > >
> : > > On Thu, Apr 25, 2024 at 9:56 PM David Smiley <dsmi...@apache.org>
> wrote:
> : > > >
> : > > > I got a test failure that reproduces:
> : > > > ./gradlew :solr:core:test --tests
> : > > >
> "org.apache.solr.uninverting.TestUninvertingReader.testSortedSetFloat"
> : > > > -Ptests.seed=5827A2FA13E7BE3C
> : > > > Based on GE
> : >
> https://ge.apache.org/scans/tests?search.relativeStartTime=P90D&search.rootProjectNames=solr-root&search.timeZoneId=America%2FNew_York&tests.container=org.apache.solr.uninverting.TestUninvertingReader&tests.test=testSortedSetFloat
> : > > > and
> : >
> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.uninverting.TestUninvertingReader.testSortedSetInteger
> : > > > (notice looking at testSortedSetFloat vs testSortedSetInteger)
> : > > > these test methods on this suite have failed in the past since the
> : > > > start of this year. I ran a "git bisect" exploration and the test
> : > > > broke as of SOLR-17097: Upgrade Solr to use Lucene 9.9.2 (#2176).
> : > > > That shipped in Solr 9.5. I wish we had reproducer-detection /
> : > > > alerts. I'll file a JIRA issue for this bug.
> : > > >
> : > > > As to the seriousness... well this affects anyone using our Legacy
> : > > > numerics (vs Points) and who uninverts them (i.e. didn't enable
> : > > > docValues, which people _should_ be doing but it's easy to forget).
> : > > >
> : > > > The Smoketest passed for me when I ran it a second time.
> : > > >
> : > >
> : > > ---------------------------------------------------------------------
> : > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> : > > For additional commands, e-mail: dev-h...@solr.apache.org
> : > >
> : >
> : > ---------------------------------------------------------------------
> : > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> : > For additional commands, e-mail: dev-h...@solr.apache.org
> : >
> : >
> :
> : --
> : http://www.needhamsoftware.com (work)
> : https://a.co/d/b2sZLD9 (my fantasy fiction book)
> :
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
--
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fantasy fiction book)
