As I recall, there were other API changes in zk 3.3 -> 3.4 that would make reverting a bit more complicated. Like the change of NIOServerCnxn.Factory -> NIOServerCnxnFactory (refactor to top level class). So reverting while keeping 3.4 usage for security would require more work to put in place some kind of shim layer.
In any case, security is meaningless without ZK 3.4, so I am not in favor of reverting. I haven't been tracking 3.4 development closely, so I don't know how much pain bugs in that release have been causing. But 3.3 has had issues too. I was just bit by ZOOKEEPER-1208 last week on a running cluster. Of course this issue is fixed in 3.3.4 and 3.4.0. But that would by my opinion for any current issues we're seeing with 3.4 as well -- let's try to get them fixed and move on instead of putting effort into backtracking for a temporary solution. --gh On Fri, Jan 27, 2012 at 7:50 AM, Ted Yu <[email protected]> wrote: > That's what we have done for internal repository. > > Some of the bugs in 3.4.x are hard to reproduce, track down and fix. > > Of course, Gary and Andrew's opinions are important. > > On Fri, Jan 27, 2012 at 7:23 AM, Todd Lipcon <[email protected]> wrote: > >> At one point I had proposed making the ZK dependency switch only for >> the security profile in the pom. The ZK 3.4.x series has been buggy so >> far - I'm sure it will stabilize within month or two, but I'd be +1 >> on reverting the non-secure build to 3.3.x in the meantime. >> >> -Todd >> >> On Thu, Jan 26, 2012 at 8:25 PM, Ted Yu <[email protected]> wrote: >> > HBase 0.92 is using zookeeper 3.4.2 >> > >> > Maybe some of you have seen this JIRA >> > https://issues.apache.org/jira/browse/ZOOKEEPER-1367 >> > It looks like a serious issue. >> > >> > Cheers >> >> >> >> -- >> Todd Lipcon >> Software Engineer, Cloudera >>
