Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
References: 
 <CALte62xJp1_PBpPQ8n+ieZUC2NHPenWV+L+zCfn9tr+3kTnC+A@mail.gmail.com>
 <CADY20s6jLYA6o7gpS4RdJ5mBt3D_yAtriqS5EULLJMuuOPs8pg@mail.gmail.com>
 <CALte62yuawf80biCqNZZxdAh4+RJZRu=o4T3mCzHK9sswhpR0w@mail.gmail.com>
 <CADfYSXShA7gw72z0FtoHmZ_1f5YY8iuXx-4uyUvpDCjTVdD7hw@mail.gmail.com>
 <1327688045.28777.YahooMailNeo@web164502.mail.gq1.yahoo.com>
 <CALte62zNdnQi_RK-T8Z+_RRAS1-9nA-dndZ3k-DiJZpfNJY_SQ@mail.gmail.com>
Message-ID: <1327693845.50981.YahooMailNeo@web164503.mail.gq1.yahoo.com>
Date: Fri, 27 Jan 2012 11:50:45 -0800 (PST)
From: Andrew Purtell <apurtell@apache.org>
Reply-To: Andrew Purtell <apurtell@apache.org>
Subject: Re: rethinking zookeeper version
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
In-Reply-To: 
 <CALte62zNdnQi_RK-T8Z+_RRAS1-9nA-dndZ3k-DiJZpfNJY_SQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Ted,=0A=0AIf I recall correctly, we did consider it.=A0You were welcome at =
the time to make this comment on the appropriate JIRA. Maybe that would hav=
e changed the decision.=0A=0AShims are ugly hacks as a rule.=0A=0AWe also m=
ay have overreached trying to be compatible with CDH3, ASF 1.0, and 0.22, a=
nd 0.23. I know the MR tests are broken against 0.23. Also a change for 1.0=
 broke against 0.23 if I recall correctly. If I want to get the tests worki=
ng against 0.23 there's some work to do. Which may break against 1.0, requi=
ring more work, which may break against ...=A0=0A=0AAnd what about subtle c=
hanges that don't break compilation but require a combinatorial explosion o=
f test configurations to identify at runtime?=0A=0AWhere does that end?=0A=
=0AMy prediction: A decision to support one version of ZooKeeper, and core,=
 with everything else YMMV.=0A=0ABest regards,=0A=0A=A0=A0 =A0 - Andy=0A=0A=
Problems worthy of attack prove their worth by hitting back. - Piet Hein (v=
ia Tom White) =0A=0A=0A----- Original Message -----=0A> From: Ted Yu <yuzhi=
hong@gmail.com>=0A> To: dev@hbase.apache.org; Andrew Purtell <apurtell@apac=
he.org>=0A> Cc: =0A> Sent: Friday, January 27, 2012 10:26 AM=0A> Subject: R=
e: rethinking zookeeper version=0A> =0A> I agree with what Andy and Gary sa=
id.=0A> =0A> In the future when we encounter incompatible API changes in a =
very=0A> important Apache project which HBase depends heavily, we do need t=
o=0A> consider providing shim so that we have some room to accommodate diff=
erent=0A> releases of the underlying project in the (short) period after ne=
w release=0A> of HBase.=0A> =0A> Cheers=0A> =0A> On Fri, Jan 27, 2012 at 10=
:14 AM, Andrew Purtell =0A> <apurtell@apache.org>wrote:=0A> =0A>>  If you d=
ig in on ZOOKEEPER-1367, this is a custom ZooKeeper embedding in a=0A>>  pr=
oduct, not a deployment scenario that one would see with HBase. I =0A> don'=
t=0A>>  want to overestimate or underestimate the importance of the issue.=
=0A>>  Currently it is under investigation and the ZK folks haven't gotten =
to =0A> the=0A>>  bottom of it. Making a decision based on this one JIRA se=
ems premature.=0A>> =0A>>  > In any case, security is meaningless without Z=
K 3.4, so I am not in=0A>>  > favor of reverting.=0A>> =0A>> =0A>>  Likewis=
e.=0A>> =0A>>  Whomever reverts the main build to ZK to 3.3 while retaining=
 3.4 for=0A>>  security would have to add shims for the NIO server construc=
tor. There is=0A>>  also a problematic Enum change.=0A>> =0A>>  Best regard=
s,=0A>> =0A>> =A0 =A0 =A0 - Andy=0A>> =0A>>  Problems worthy of attack prov=
e their worth by hitting back. - Piet Hein=0A>>  (via Tom White)=0A>> =0A>>=
 =0A>>  ----- Original Message -----=0A>>  > From: Gary Helmling <ghelmling=
@gmail.com>=0A>>  > To: dev@hbase.apache.org=0A>>  > Cc:=0A>>  > Sent: Frid=
ay, January 27, 2012 9:16 AM=0A>>  > Subject: Re: rethinking zookeeper vers=
ion=0A>>  >=0A>>  > As I recall, there were other API changes in zk 3.3 -> =
3.4 that =0A> would=0A>>  > make reverting a bit more complicated.=A0 Like =
the change of=0A>>  > NIOServerCnxn.Factory -> NIOServerCnxnFactory (refact=
or to top =0A> level=0A>>  > class).=A0 So reverting while keeping 3.4 usag=
e for security would=0A>>  > require more work to put in place some kind of=
 shim layer.=0A>>  >=0A>>  > In any case, security is meaningless without Z=
K 3.4, so I am not in=0A>>  > favor of reverting.=A0 I haven't been trackin=
g 3.4 development =0A> closely,=0A>>  > so I don't know how much pain bugs =
in that release have been =0A> causing.=0A>>  > But 3.3 has had issues too.=
=A0 I was just bit by ZOOKEEPER-1208 last=0A>>  > week on a running cluster=
.=A0 Of course this issue is fixed in 3.3.4 and=0A>>  > 3.4.0.=A0 But that =
would by my opinion for any current issues we're=0A>>  > seeing with 3.4 as=
 well -- let's try to get them fixed and move on=0A>>  > instead of putting=
 effort into backtracking for a temporary solution.=0A>>  >=0A>>  > --gh=0A=
>>  >=0A>>  >=0A>>  > On Fri, Jan 27, 2012 at 7:50 AM, Ted Yu <yuzhihong@gm=
ail.com> =0A> wrote:=0A>>  >>=A0 That's what we have done for internal repo=
sitory.=0A>>  >>=0A>>  >>=A0 Some of the bugs in 3.4.x are hard to reproduc=
e, track down and =0A> fix.=0A>>  >>=0A>>  >>=A0 Of course, Gary and Andrew=
's opinions are important.=0A>>  >>=0A>>  >>=A0 On Fri, Jan 27, 2012 at 7:2=
3 AM, Todd Lipcon =0A> <todd@cloudera.com>=0A>>  > wrote:=0A>>  >>=0A>>  >>=
>=A0 At one point I had proposed making the ZK dependency switch =0A> only =
for=0A>>  >>>=A0 the security profile in the pom. The ZK 3.4.x series has b=
een =0A> buggy so=0A>>  >>>=A0 far=A0 - I'm sure it will stabilize within m=
onth or two, =0A> but I'd=0A>>  > be +1=0A>>  >>>=A0 on reverting the non-s=
ecure build to 3.3.x in the meantime.=0A>>  >>>=0A>>  >>>=A0 -Todd=0A>>  >>=
>=0A>>  >>>=A0 On Thu, Jan 26, 2012 at 8:25 PM, Ted Yu =0A> <yuzhihong@gmai=
l.com>=0A>>  > wrote:=0A>>  >>>=A0 > HBase 0.92 is using zookeeper 3.4.2=0A=
>>  >>>=A0 >=0A>>  >>>=A0 > Maybe some of you have seen this JIRA=0A>>  >>>=
=A0 > https://issues.apache.org/jira/browse/ZOOKEEPER-1367=0A>>  >>>=A0 > I=
t looks like a serious issue.=0A>>  >>>=A0 >=0A>>  >>>=A0 > Cheers=0A>>  >>=
>=0A>>  >>>=0A>>  >>>=0A>>  >>>=A0 --=0A>>  >>>=A0 Todd Lipcon=0A>>  >>>=A0=
 Software Engineer, Cloudera=0A>>  >>>=0A>>  >=0A>> =0A>