As you can see by all the bugs introduced by the recent large scale refactorings around core container, the tests will not prevent this. SolrCloud is even worse in this regard - many things are difficult to test or rely on timing or this or that. We could use way more tests than we have and even then there are many difficulties in testing a distributed system.
If it was an all or nothing change (I'm not convinced it is), I would certainly vote against at this point in time. We have years of hardening around the current zk code at this point Mark > On Dec 14, 2013, at 4:04 PM, Alan Woodward <a...@flax.co.uk> wrote: > > >> On 14 Dec 2013, at 19:58, Mark Miller wrote: >> >> I’ve looked at it over the years, but honestly, for most things, I don’t >> think switching would help much other than rewrite code that has been fairly >> hardened with fresh code that is just likely to introduce new bugs. > > Well, that's what our comprehensive and robust test suite is for :-) I see > what you mean, although on the flip side, using a third-party library that's > had lots of testing outside Solr means that it may already pick up corner > cases that we haven't run in to. > >> >> Targeted use of it for specific things could make sense, but that’s the type >> of thing I think we should look at a JIRA issue at a time. > > Unfortunately I think it'd be all-or-nothing, because we'd have to replace > SolrZkClient with CuratorFramework whenever we wanted to use a recipe. > >> >> - Mark >> >>> On Dec 14, 2013, at 2:15 PM, Alan Woodward <a...@flax.co.uk> wrote: >>> >>> Evening all, >>> >>> I discovered the Apache Curator project yesterday >>> (http://curator.apache.org/index.html), which seems to make interaction >>> with Zookeeper much easier. What do people think about using it for >>> SolrCloud? In particular, the LeaderLatch, Barrier and NodeCache recipes >>> would make the Overseer and OverseerCollectionProcessor a lot simpler. >>> >>> Alan Woodward >>> www.flax.co.uk >
