OK, to clarify, you're saying that we still haven't decided about further improvements to the 3.5 branch after 3.5.2. I think it is important to clarify that the point for me isn't about this improvement but any other improvement that we can push to 3.6.0. I really want to emphasize that it isn't about ZK-2024 only.
-Flavio > On 25 Mar 2016, at 09:35, Rakesh Radhakrishnan <rakeshr.apa...@gmail.com> > wrote: > > Are you asking about merging this feature into 3.5.2 version. I'm telling > that, will first merge this feature to trunk and later(after 3.5.2 release > activities) if everyone agrees will include this in 3.5.3 or so. > > -Rakesh > > > On Fri, Mar 25, 2016 at 2:57 PM, Flavio Junqueira <f...@apache.org> wrote: > >> I'm not sure we have decided about 3.5, Rakesh, have we? >> >> -Flavio >> >>> On 25 Mar 2016, at 09:13, Rakesh Radhakrishnan <rakeshr.apa...@gmail.com> >> wrote: >>> >>> 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 >>>>> >>>> >> >>
