And to emphasize the brilliance of ZkShardTerms (in turn, on RAFT which is
it's basis/genesis), we might not even need replica states. ZkShardTerms +
live_nodes is probably enough. Credit to Dat on this; we were just in an
email exchange about this stuff.
~ David Smiley
Apache Lucene/Solr Search
On Fri, Oct 14, 2022 at 6:11 AM Mark Miller wrote:
> I don’t have much to say about the proposal, other than to say that if an
> election ever ends up involving syncing up and exchanging data, doing that
> just in time is probably less than ideal for most of the more common uses
> cases.
>
I sho
Agree too,
Are you trying to optimize for nodes in a large cluster going down and coming
up again within a short time period withuot another replica being elected
leader?
I'd prefer if Solr any rewrite would use proven recipies from e.g. Curator
instead of rolling our own.
If we have complex e
"just in time is probably less than ideal for most of the more common uses
cases."
Agree
On Fri, Oct 14, 2022, 9:11 PM Mark Miller wrote:
> I don’t have much to say about the proposal, other than to say that if an
> election ever ends up involving syncing up and exchanging data, doing that
> ju
I don’t have much to say about the proposal, other than to say that if an
election ever ends up involving syncing up and exchanging data, doing that
just in time is probably less than ideal for most of the more common uses
cases.
That’s just an aside though. Id be more interested in seeing the pro
Created https://issues.apache.org/jira/browse/SOLR-16463
Will make a PR for 9.0
Jan
> 14. okt. 2022 kl. 00:56 skrev David Smiley :
>
> Looks like we need to downgrade the Docker image to JDK 11 :-(. Or one in
> between maybe.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://
