Re: waitForState after collection creation is dumb

I don’t recall, but it makes sense. That would be a pretty janky database. It’s a race around the client seeing the collection and seeing it in full. It wouldn’t be as bad if the full collection state was just written out rather than the super legacy related, build it up piece by piece, but even

Re: waitForState after collection creation is dumb

Ah, unless someone fixed it since the last time Mark Miller ranted about it, it's rooted in the fact that the call to create a collection returns to the user before the collection is ready to use. IIRC the rant said something like "what database would return from CREATE TABLE before the table was c

Re: Query Limits - extending timeAllowed to implement thread CPU/memory limits for a query

doh, cut/paste error https://issues.apache.org/jira/browse/SOLR-17140 On Tue, Feb 6, 2024 at 5:02 PM David Smiley wrote: > I will look at this! > >- Ticket for my refactoring >https://issues.apache.org/jira/browse/SOLR-1714 > > 1714, ehh? :-) > > Another thought I had that I want to shar

Re: [VOTE] Release Solr 9.5.0 RC2

Actually, credit to Shawn for discovring the bug and to Houston for fixing it. :) > 7. feb. 2024 kl. 00:50 skrev Jan Høydahl : > > Thanks for catching this before the release Houston! Your PR and bats test > looks solid. Let's r

Re: [VOTE] Release Solr 9.5.0 RC2

Thanks for catching this before the release Houston! Your PR and bats test looks solid. Let's re-spin.. Jan > 7. feb. 2024 kl. 00:15 skrev Houston Putman : > > Sorry everyone, I have to -1 this. Unfortunately certain solr.in.sh > functionality has broken due to a bug introduced while trying to

Re: [VOTE] Release Solr 9.5.0 RC2

Sorry everyone, I have to -1 this. Unfortunately certain solr.in.sh functionality has broken due to a bug introduced while trying to improve the envVar handling. More details provided here: https://github.com/apache/solr/pull/2250 ( SOLR-15960 ) -

Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions

: In my mind, we, Solr, have four options : D) Continue with g'old JIRA My vote is (still) for D ... I don't see that changing unless/until Apache starts self-hosting GitHub Enterprise, and elimiantes the need for people to accept the github.com ToS (and Country restrictions). Even then... i

Re: [VOTE] Release Solr 9.5.0 RC2

+1 (binding) SUCCESS! [0:33:17.981563] Kevin Risden On Tue, Feb 6, 2024 at 3:35 PM Arrieta, Alejandro < aarri...@perrinsoftware.com> wrote: > Hello Team, > > SUCCESS! [0:44:46.772429] > > docker full and slim created fine. > > +1 non binding > > Kind Regards, > Alejandro Arrieta > > > On Tue,

Re: Query Limits - extending timeAllowed to implement thread CPU/memory limits for a query

I will look at this! - Ticket for my refactoring https://issues.apache.org/jira/browse/SOLR-1714 1714, ehh? :-) Another thought I had that I want to share is that I think the query tracking and cancellation could use the same QueryTimeout infrastructure. I don't like that it adds its own

waitForState after collection creation is dumb

Hey... about about that click-bait title; ehh? :-D I've noticed that basically any SolrCloudTestCase will create a collection and then call waitForState. I think this is dumb; do we ask our clients to do the same? Then why should our tests do this? I can understand some tests may have specializ

Re: [VOTE] Release Solr 9.5.0 RC2

Hello Team, SUCCESS! [0:44:46.772429] docker full and slim created fine. +1 non binding Kind Regards, Alejandro Arrieta On Tue, Feb 6, 2024 at 1:37 PM Houston Putman wrote: > +1 (binding) > > SUCCESS! [0:32:51.658820] > > I also built both Docker images and ran the Solr Operator integration

Re: [VOTE] Release Solr 9.5.0 RC2

+1 (binding) SUCCESS! [0:32:51.658820] I also built both Docker images and ran the Solr Operator integration tests with the full image: ••• Ran 23 of 23 Specs in 450.649 seconds SUCCESS! -- 23 Passed | 0 Failed | 0 Pending | 0 Skipped - Houston On Tue, Feb 6, 2024 at 11:43

[VOTE] Release Solr 9.5.0 RC2

Please vote for release candidate 2 for Solr 9.5.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/solr/solr-9.5.0-RC2-rev-b03df01e89e64bc897a6be93de00af9ded2ee99b You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.

Re: [VOTE] Release Solr 9.5.0 RC1

I think this is assumed from the discussion above, but because the releaseWizard suggests a formal "FAILED" email: This vote has FAILED. Reason for fail is: re-spinning the release for SOLR-17149. On Mon, Feb 5, 2024 at 1:55 PM Jason Gerlowski wrote: > It's probably cleanest to create a new ti

Re: Query Limits - extending timeAllowed to implement thread CPU/memory limits for a query

To save folks some clicking around, and to provide a little more detail, here are a few links. - The first step was to refactor/replace QueryTimeoutImpl: PR https://github.com/apache/solr/pull/2237. - Building on that will be Andrzej's PR https://github.com/apache/solr/pull/2244/commi

Re: Query Limits - extending timeAllowed to implement thread CPU/memory limits for a query

I have updated the jira with my vote and totally agree that solr lacks this way to limit the usage and a single query bringing all the nodes in the cluster down. I'd love to review/contribute to PR . Thank you for bringing up this issue Andrzej. On Mon, Feb 5, 2024 at 4:16 PM Andrzej Białecki