Re: Replicas stuck in DOWN state

I think SolrCloud ought to make a conditional state change based on the ZooKeeper version of live_nodes. Thus a request to change the node's state would fail if the request included an old state version. In this case the client would re-fetch the state and retry or change its mind on whether it's

Re: Splitting the collection API into separate per-command class files

Would the individual commands register via classpath scanning or static initializers or is this something that @Endpoint already does for us? In general, I would be in favor of splitting out the commands, although some of them might still make sense to group together. On Thu, Apr 29, 2021 at 4:05

Re: Post Tool

Documentation needs maintenance long term -- it can say things or show snippets that aren't true eventually or eventually stop working. Just keep that in mind. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Thu, Apr 29, 2021 at 4:19 PM Eric Pugh w

Splitting the collection API into separate per-command class files

For a long time, I have not been fond of how the code for our collection APIs are organized. I would prefer to see more separation between the commands (thus no long class files implementing many commands), and fewer places to touch generally. If more of a command's logic is in its own source fil

Re: Post Tool

I’d be interested in picking up the baton on that idea….I could see adding both a curl example, but also a native Powershell example.Curl on windows is also an alias to powershell methods, so it doesn’t quite work always. I could imagine have three tabs to demonstrate this. > On Apr

Re: Proposal to pin the Lucene snapshot version on main

Hi, +1 to pin. Kind Regards, Furkan KAMACI On Thu, Apr 29, 2021 at 10:45 PM David Smiley wrote: > +1 Jan, that sounds complementary to what I propose. We'd get > notifications via Jenkins that there are some compatibility issues. But > we'd still pin a version and upgrade at a time of our ch

Re: Proposal to pin the Lucene snapshot version on main

+1 Jan, that sounds complementary to what I propose. We'd get notifications via Jenkins that there are some compatibility issues. But we'd still pin a version and upgrade at a time of our choosing. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Th

Re: Proposal to use AffinityPlacementFactory as default in 9.0

The new code has no notion of existing collections so that can’t be an issue. It relies on detailed knowledge of the collection for which the Collection API is working, a related collection when applicable, and per node metrics/system properties. Ilan On Thu 29 Apr 2021 at 19:27, Gus Heck wrote:

Re: Proposal to use AffinityPlacementFactory as default in 9.0

IIRC it wasn't the nodes calculated, but rather the number of collections already in the cluster that caused the issue. See https://issues.apache.org/jira/browse/SOLR-14665 On Thu, Apr 29, 2021 at 1:09 PM Ilan Ginzburg wrote: > Yes Gus, this was verified, AB did some work around this. > Slowdown

Re: Proposal to use AffinityPlacementFactory as default in 9.0

Yes Gus, this was verified, AB did some work around this. Slowdown is linear on all cardinalities IIRC and absolute values are low. For example computing placement of 10K replicas in less than 1 sec on 5000 nodes, less than 3 sec on a 20K nodes cluster, placing 200K replicas on 5000 nodes, most unf

Re: [VOTE] Solr Operator Logo

Logo: L-3, L-2 Icon: I-1 (binding) On Wed, Apr 28, 2021 at 1:02 PM Jason Gerlowski wrote: > > (binding) > Logo vote: L4, L-1 > Icon vote: I-4 > > On Tue, Apr 27, 2021 at 8:34 PM Gus Heck wrote: > > > > (binding) > > L-2 L-1 L-3 > > I-3 I-2 I-1 > > > > On Tue, Apr 27, 2021 at 5:00 PM Houston

Re: Proposal to use AffinityPlacementFactory as default in 9.0

Possibly it was discussed elsewhere or in related tickets and I missed it, but has the scaling scenario that caused problems (time to create collections increasing linearly with increasing number of collections) been tested and compared with the result that lead to deprecation of autoscaling? On T

Re: Proposal to pin the Lucene snapshot version on main

It could be feasible to let Jenkins do a periodic run (weekly?) of main branch with lucene SNAPSHOT. We can perhaps define a gradle property to override lucene version? -Dlucene.version=10.0.0-SNAPSHOT which Jenkins could easily trigger. I think a similar thought has been discussed before. Jan

Re: Proposal to use AffinityPlacementFactory as default in 9.0

Expliciting (I think) your suggestion from the Slack thread Jan: - Add support for a new solr.xml config called something like forceDefaultLegacyPlacementStrategy - Do not add anything in solr.xml At runtime: - If a placement plugin is explicitly configured (existing plugin config

Proposal to use AffinityPlacementFactory as default in 9.0

Bringing over a discussion from Slack In 9.0, the old Autoscaling is gone, and instead we have cluster level "Placement Plugins", see https://nightlies.apache.org/Solr/Solr-reference-guide-main/replica-placement-plugins.html The

Re: Proposal to pin the Lucene snapshot version on main

We should still have some way of detecting these breakages early rather than later (or worse yet after lucene has released something). The easiest time to fix a problem is before someone else built on top of it. On Thu, Apr 29, 2021 at 11:15 AM Jason Gerlowski wrote: > +1 > > On Thu, Apr 29, 202

Re: Proposal to pin the Lucene snapshot version on main

+1 On Thu, Apr 29, 2021 at 11:12 AM Jan Høydahl wrote: > > +1 to pin. There will probably be a few more months until 9.0 given that 8.9 > must be released first etc. > > Jan > > 29. apr. 2021 kl. 17:08 skrev David Smiley : > > There have been some discussions previously about whether to pin the

Re: Proposal to pin the Lucene snapshot version on main

+1 to pin. There will probably be a few more months until 9.0 given that 8.9 must be released first etc. Jan > 29. apr. 2021 kl. 17:08 skrev David Smiley : > > There have been some discussions previously about whether to pin the Lucene > snapshot version until 9.0 is out, so that we update it

Proposal to pin the Lucene snapshot version on main

There have been some discussions previously about whether to pin the Lucene snapshot version until 9.0 is out, so that we update it manually instead of it being ~daily. Most recently in Slack but also this thread "Solr fails with current lucene-9.0.0-SNAPSHOT (LUCENE-9387)". I think the rate of s

Re: Solr Roadmap (and 9.0 release planning)

> The way that we get more "selling points" into it (if we need them), is to > stop releasing 8.x releases. I tend to agree on this in general - I have been selective on what to backport for some time - let new features arrive in 9.0 and only backport to 8.9 if it's a bugfix or some code requir

Re: Post Tool

Yea, let's add some warnings and keep post tool for demo purposes. Perhaps in the tutorial https://solr.apache.org/guide/8_8/solr-tutorial.html we could add cURL examples for indexing the data as well as post.jar (using tabs like we do with v1/v2 api)? We can also do a better job suggesting where

Re: Post Tool

You need an extra step to install curl on Windows. I know it may seem esoteric but I bet there are still a fair share of folks who are on Windows. D. On Wed, Apr 28, 2021 at 11:04 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > We should remove the post tool > Altogether. Curl is g