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
> >
>

Reply via email to