I very much agree. That code is the root of a very surprising amount of evil and has been for a surprisingly long time.
There is a long list of reasons that I won’t iterate of why I don’t see that as likely happening though - just starting with Ive brought it up to various people over a couple years and gotten pushback just at the top. Roughly, it’s on the scale of work and invasiveness, even with some incremental paths, that I don’t see the path or resources to seriously consider it myself. You can go back through jira history for quite a while before you find that kind of item not looking out of place. Mark On Wed, Sep 29, 2021 at 2:05 AM Andrzej Białecki <[email protected]> wrote: > +1 to start working towards using Curator, this is long overdue and sooner > or later we need to eat this frog - as you dig deeper and deeper it turns > out that many issues in Solr can be attributed to our home-grown ZK code, > there are maybe 2 people on the Solr team who understand what’s going on > there (and I’m certainly not one of them!). And the maintenance cost is > just too high over time. > > — > > Andrzej Białecki > > On 28 Sep 2021, at 21:31, Mark Miller <[email protected]> wrote: > > P.S. this is not actually the zookeeper design I would submit to any > competition :) > > I’ve gone different routes in addressing the zookeeper short fall. This > one is relatively easy, impactful and isolated for the right developer. > > Personally, with fewer scale and isolation limits, by the far the best > thing I’ve done is remove almost all of our zk recipes and custom stuff and > use Apache curator and replace our stuff as well as improve and expand on > things using their large stable of well behaving recipes. I don’t think raw > zookeeper is good for a project of more than a few people at most. But I > wouldn’t toss that out there, it’s a much larger undertaking, no one is > going to bite on that in passing. > > Mark > -- > - Mark > > http://about.me/markrmiller > > > -- - Mark http://about.me/markrmiller
