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