> Insight from the creators/reviewers is probably the most critical > signal. e.g. how much risk is there, how well is it tested, is the > value vs the risk worth it.
Patrick, as I mentioned previously, this patch went through many rounds of review (reviewboard has 26 versions). We ended up with a simple algorithm, very localized in terms of code changes and much simpler than the code currently in place, and one for which we can reason about correctness (in the Jira). Besides new unit tests, Kfir had done extensive system testing, and actually improved ZK's system test suit for that purpose. Results attached to the Jira show that there is 10x-20x throughput improvement. Kfir did an excellent job - I haven't seen many patches recently with similar level of testing. Here are two scenarios for which the improvements especially matter: 1. Deployment using observers. The observers run commit processor too, so they block all their pipeline for every write, of course this stalls all operations coming from their DC to the ZK. 2. Any two applications with different workload trying to use the same ZooKeeper. This patch brings us much closer to client isolation (if you're worried about security, you should be worried about isolation) I think the fact that both Twitter and Facebook have an internal version of this patch speaks for itself. I totally understand Chris's prioritization. I'd like to commit it to trunk for now, and then you guys can decide which release to add this in. I understand much less blanket stability concerns that are stated (in other threads about this) without reviewing the work or evaluating its benefits. While we try to encourage more contribution to ZK, such approach makes people trying to contribute feel like their work is being put in the drawer without due consideration. Alex On Mon, Mar 21, 2016 at 9:54 PM, Patrick Hunt <ph...@apache.org> wrote: > fwiw, my 0.02. > > The other comments on this thread, while not all aligned, make sense > to me. I don't see anything I outright disagree with. > > Based on feedback we got during the recent meetup and others > anecdotally (e.g. Raul's and other insights) it sounded like a number > of community members are already using 3.5 for "production" workloads. > They seemed relatively happy with the current stability levels. > > My concern with pulling in non-critical changes at this point, > regardless the source, is the risk/reward in 3.5 vs postponing to 3.6. > We don't have a huge amount of testing that we do within the > development community that will catch regressions. Just because we > don't ship something in 3.5 doesn't mean it's not available, it's just > not available in the release. > > So then it becomes a question of delaying the features/improvements > already in 3.5 vs "just one more". I could see it go either way. > Insight from the creators/reviewers is probably the most critical > signal. e.g. how much risk is there, how well is it tested, is the > value vs the risk worth it. > > Patrick > > On Mon, Mar 21, 2016 at 2:11 PM, Chris Nauroth <cnaur...@hortonworks.com> > wrote: > > I've had a chance to do a cursory first review of ZOOKEEPER-2024 (major > throughput improvement with mixed workloads). Big thanks to Kfir for > authoring the patch and Alex for championing it. It's very interesting. > > > > At this point, as release manager for 3.5.2-alpha, I am leaning towards > not including it in this release. This is not so much a statement on this > patch itself as it is an acknowledgment of competing priorities. We still > have a fair number of blocker bugs targeted to 3.5.2-alpha. I expect we're > all going to need to focus on those blockers now in order to get a release > ready in the next several weeks. > > > > I think the feature is very compelling though. I would like us to > seriously consider including it before 3.5 GA. I don't see any > compatibility concerns in the patch, so that should make it easy to include > the patch later. > > > > Somewhat related to that, I'd like to see if we can move faster on a > 3.5.3 release after 3.5.2. Recent mailing list discussions indicate that > the community would like to see a quicker release cadence. Perhaps 3.5.3 > can focus on ZOOKEEPER-2024, API stability, and a handful of further > blockers. > > > > --Chris Nauroth >
