It would be a pretty odd edge case. The enum method would typically not be used in high cardinality cases and limit:-1 means an overrequest is not needed. I personally don't think this is a blocker.
Joel Bernstein http://joelsolr.blogspot.com/ On Mon, May 2, 2022 at 12:43 PM Michael Gibney <mich...@michaelgibney.net> wrote: > Gus said most of what I have to say -- this affects an odd edge case: > explicit positive overrequest _and_ method:enum _and_ limit:-1. This would > be a pretty pathological combination; but even so, the consequence would be > to turn an unlimited (limit:-1) request into a limited one (limit:n, n>=0) > -- it would not be subtle in how that would manifest. So I'll retract my > earlier statement ("I'd be surprised if this turns out to be a blocker for > 9.0"). > > On Mon, May 2, 2022 at 11:45 AM Gus Heck <gus.h...@gmail.com> wrote: > >> Also this changes my vote to -1 >> >> On Mon, May 2, 2022 at 11:44 AM Gus Heck <gus.h...@gmail.com> wrote: >> >>> Some offline discussion indicates that this is more than just SKG and it >>> looks like Michael will look into it, so I've filed >>> https://issues.apache.org/jira/browse/SOLR-16176 as a blocker and >>> assigned to him. >>> >>> On Mon, May 2, 2022 at 11:03 AM Jan Høydahl <jan....@cominvent.com> >>> wrote: >>> >>>> Tried some seeds from Jenkins failures for this same test, and found >>>> another reproducible seed: 19DF63E9537FFBA3 >>>> >>>> On the face of it, it seems like a corner case bug, but could of course >>>> be a generic enum JSON Facet bug that has lived with us for some time? >>>> I'll wait a bit more to gather more insight on this. >>>> Gus, have you created a JIRA? >>>> >>>> Jan >>>> >>>> 2. mai 2022 kl. 16:01 skrev Gus Heck <gus.h...@gmail.com>: >>>> >>>> >>>> I was hoping someone more familiar with SKG's test/code that I found a >>>> failure for might chime in. It looks like it's a case where enum facets are >>>> not producing all results produced for default faceting, which seems >>>> possibly bad, but I am not familiar with this code at all. This probably is >>>> localized to Semantic Knowledge Graphs (which after some digging is what >>>> SKG stands for... be nice if that were in the comments for the class)... so >>>> the question is do we want to release with a known break in that feature I >>>> guess. I'm inclined to say no, but I am certainly not going to be able >>>> to dig into SKG's to fix this in a timely fashion. So I guess the question >>>> is is SKG important enough to someone out there to fix it soon? >>>> >>>> Also looks like the code iterates across possible parameter values and >>>> fails on the first one to go wrong so there may be other failure cases for >>>> STREAM or SMART hiding behind this... >>>> >>>> -Gus >>>> >>>> On Mon, May 2, 2022 at 6:55 AM Jan Høydahl <jan....@cominvent.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> If I close the vote now, it will technically pass with four +1s, one >>>>> -1 and one -0. A bit too fragile result IMO. >>>>> >>>>> I would too like to understand the severity of the configsets bug, and >>>>> whether it is serious enough to stop the release. >>>>> As I understand the issue, it ONLY affects those creating a new >>>>> configset based on another one in ZK. >>>>> I.e. there are many workarounds for this bug >>>>> - Use an authenticated user when creating configset (and not an >>>>> "untrusted" one) >>>>> - Upload a new configset rather than basing it on an existing? >>>>> - Upload configset directly to Zookeeper >>>>> >>>>> Please verify or shoot down my assumption. If my assumption is >>>>> correct, I'll keep my +1 vote, and wait for a few more +1s before closing >>>>> the vote. If the issue is indeed more serious and there are more -1's, >>>>> I'll >>>>> happily respin after the fix. >>>>> >>>>> Jan >>>>> >>>>> >>>>> 29. apr. 2022 kl. 21:03 skrev Gus Heck <gus.h...@gmail.com>: >>>>> >>>>> -0 for now, pending discussion of severity... I have hit a reproducing >>>>> failure: >>>>> >>>>> ./gradlew :solr:core:test --tests >>>>> "org.apache.solr.search.facet.TestCloudJSONFacetSKGEquiv.testRandom" >>>>> -Ptests.jvms=5 -Ptests.jvmargs=-XX:TieredStopAtLevel=1 >>>>> -Ptests.seed=C730F33909C71234 -Ptests.badapples=false >>>>> -Ptests.file.encoding=UTF-8 >>>>> >>>>> On Fri, Apr 29, 2022 at 1:28 PM Kevin Risden <kris...@apache.org> >>>>> wrote: >>>>> >>>>>> Smoketester passed on the second try for me: SUCCESS! [1:29:24.214674] >>>>>> >>>>>> The first failure was "gradlew :solr:core:test --tests >>>>>> "org.apache.solr.cloud.HttpPartitionOnCommitTest.test" -Ptests.jvms=4 >>>>>> -Ptests.jvmargs=-XX:TieredStopAtLevel=1 -Ptests.seed=66730F3AEF630DB6 >>>>>> -Ptests.badapples=false -Ptests.file.encoding=US-ASCII". I haven't >>>>>> reproduced it yet. >>>>>> >>>>>> However it looks like the configsets API is broken with one of the >>>>>> simpler examples. Eric Pugh found this the other day and asked me to >>>>>> check on 9.0 RC4: https://issues.apache.org/jira/browse/SOLR-16164 >>>>>> >>>>>> I'm still poking around the release today. >>>>>> >>>>>> Based on the configset api error - I'm -1 for releasing. >>>>>> >>>>>> Kevin Risden >>>>>> >>>>>> >>>>>> On Fri, Apr 29, 2022 at 11:26 AM Mike Drob <md...@apache.org> wrote: >>>>>> >>>>>>> +1 (binding) >>>>>>> >>>>>>> >>>>>>> Smoketester succeeded with Java 11 and Java 17 -- SUCCESS! >>>>>>> [2:04:03.678208] >>>>>>> >>>>>>> Unlike for some others, this succeeded on my first try. I guess I'm >>>>>>> just lucky :) >>>>>>> >>>>>>> >>>>>>> Tested building an application that uses EmbeddedSolrServer and >>>>>>> depends on our maven artifacts - validated SOLR-16157, SOLR-16117 >>>>>>> >>>>>>> Tested a mixed state cluster with 8.11.1 and 9.0.0 nodes (no >>>>>>> security). Queries worked as expected. >>>>>>> Tested a rolling upgrade from 8.11.1 to 9.0.0 with basic >>>>>>> authentication enabled. Queries failed (as expected) at first, but then >>>>>>> succeeded when setting solr.pki.sendVersion=v1 and >>>>>>> solr.pki.acceptVersions=v1,v2on the Solr 9 node, as described in >>>>>>> our ref guide and upgrade notes. >>>>>>> >>>>>>> Manually checked for license headers in source release, missing >>>>>>> headers on the following: >>>>>>> * SYSTEM_REQUIREMENTS.md >>>>>>> * solr/core/src/resources/SystemCollection*.xml >>>>>>> * lots and lots of stuff under solr-ref-guide, unclear which pieces >>>>>>> of this are our code and which are copied from external sources. >>>>>>> * modules/*/README.md >>>>>>> >>>>>>> Will file a follow up JIRA for the license issues. >>>>>>> >>>>>>> On Wed, Apr 27, 2022 at 8:15 AM Jan Høydahl <jan....@cominvent.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Please vote for release candidate 4 for Solr 9.0.0 >>>>>>>> >>>>>>>> The artifacts can be downloaded from: >>>>>>>> >>>>>>>> https://dist.apache.org/repos/dist/dev/solr/solr-9.0.0-RC4-rev-d6e36d590896755ca962c6d2ddedf78ca4f463cc >>>>>>>> >>>>>>>> You can run the smoke tester directly with this command: >>>>>>>> >>>>>>>> python3 -u dev-tools/scripts/smokeTestRelease.py \ >>>>>>>> >>>>>>>> https://dist.apache.org/repos/dist/dev/solr/solr-9.0.0-RC4-rev-d6e36d590896755ca962c6d2ddedf78ca4f463cc >>>>>>>> >>>>>>>> You are encouraged to do an extra thorough test and manual >>>>>>>> inspection beyond >>>>>>>> running the smoketester, since this is a major release. >>>>>>>> >>>>>>>> You can build a release-candidate of the official docker image >>>>>>>> using the following command: >>>>>>>> >>>>>>>> DIST_BASE=https://dist.apache.org/repos/dist/dev/solr && \ >>>>>>>> >>>>>>>> RC_FOLDER=solr-9.0.0-RC4-rev-d6e36d590896755ca962c6d2ddedf78ca4f463cc >>>>>>>> && \ >>>>>>>> docker build >>>>>>>> $DIST_BASE/$RC_FOLDER/solr/docker/Dockerfile.official \ >>>>>>>> --build-arg >>>>>>>> SOLR_DOWNLOAD_URL=$DIST_BASE/$RC_FOLDER/solr/solr-9.0.0.tgz \ >>>>>>>> -t solr-rc:9.0.0-4 >>>>>>>> >>>>>>>> The vote will be open for at least 72 hours i.e. until 2022-04-30 >>>>>>>> 13:00 UTC. >>>>>>>> >>>>>>>> [ ] +1 approve >>>>>>>> [ ] +0 no opinion >>>>>>>> [ ] -1 disapprove (and reason why) >>>>>>>> >>>>>>>> Here is my +1 >>>>>>>> >>>>>>>> SUCCESS! [0:56:56.134141] >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>>>> >>>>>>>> >>>>> >>>>> -- >>>>> http://www.needhamsoftware.com (work) >>>>> http://www.the111shift.com (play) >>>>> >>>>> >>>>> >>>> >>>> -- >>>> http://www.needhamsoftware.com (work) >>>> http://www.the111shift.com (play) >>>> >>>> >>>> >>> >>> -- >>> http://www.needhamsoftware.com (work) >>> http://www.the111shift.com (play) >>> >> >> >> -- >> http://www.needhamsoftware.com (work) >> http://www.the111shift.com (play) >> >
