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 election rules, then perhaps we could have several election groups, so first try to elect from nodes in preferred leaders group, then if that fails, elect between remaining eligible nodes. Jan > 14. okt. 2022 kl. 12:21 skrev Noble Paul <noble.p...@gmail.com>: > > "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 <markrmil...@gmail.com> 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. >> >> That’s just an aside though. Id be more interested in seeing the proposal >> connect problems with solutions. My quick read makes me think the goal is >> some dimension of scale (I’m guessing a lazy dimension, usually no the most >> common Solr architecture in my experience fwiw). But I don’t see what the >> problems are for that dimension of scale or how to connect proposals to >> solutions to the problems. Unless I’m just missing it. >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
