Thanks to Kfir and Alex for the continuous effort in contributing this imprv. Since the effort is going on to release a stable 3.5 version this feature is not getting much attention from the community.
+1 for pushing this to trunk. Later based on community feedback will back port to 3.5 branch. -Rakesh On Tue, Mar 22, 2016 at 1:21 PM, Alexander Shraer <shra...@gmail.com> wrote: > > 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 > > >