There are quite a few benefits to using grpc imo. It's come up a few times where I've been part of the discussion - ala we make it b/w compat it would be a good move imo. Then the question becomes what else do we fix at the same time? e.g. make version fields 64 bit rather than 32? etc... there are a bunch of zk4 such jiras that could be addressed at the same time (and likely in a b/w compat way - ie zk3)
That said, we added things like rest in the past for similar reasons and it never really took off... Would be a shame to see the same here. Patrick On Mon, Nov 18, 2019 at 6:48 AM Jordan Zimmerman <[email protected]> wrote: > > That looks like great work. In order to address the issues, why not > build on top of curator (https://curator.apache.org)? > > (Note: I'm the main author of Curator). I'd definitely try to make > something like Curator for gRPC. I'm not sure exactly what that means at > this point. But, my main goal is to enable non-JVM clients. We have C, > python and few others now but they always lag with changes and are hard to > maintain. > > -JZ > > > On Nov 18, 2019, at 9:45 AM, Jörn Franke <[email protected]> wrote: > > > > That looks like great work. In order to address the issues, why not > build on top of curator (https://curator.apache.org)? > > > > I could support in case question rise with SASL, but I am not sure yet > if I find the time to actively develop for this unfortunately > > > >> Am 18.11.2019 um 15:25 schrieb Jordan Zimmerman < > [email protected]>: > >> > >> Hi Folks, > >> > >> I've written a proof of concept implementation of a ServerCnxnFactory > that implements gRPC. The goal is to make it possible to easily write > ZooKeeper clients in non-JVM languages. Using the proof of concept I was > able to write a Golang client easily. What's the interest level of > something like this? Let's discuss if it's worth pursuing. I'd be willing > to move this from proof of concept to production but I'll need help (1 or 2 > co-developers). > >> > >> If you want to try it, I've pushed the Golang client and some > instructions here (let me know if you have any issues - I'm a go neophyte). > Note: "zookeeper/test.go" is the interesting file: > >> > >> https://github.com/Randgalt/zkgrpc < > https://github.com/Randgalt/zkgrpc> > >> > >> Here's the proof of concept on the ZK server side (the interesting > files are RpcServerCnxn.java, RpcServerCnxnFactory.java, > RpcZooKeeperServer.java and zookeeper.proto): > >> > >> > https://github.com/apache/zookeeper/compare/master...Randgalt:wip-grpc < > https://github.com/apache/zookeeper/compare/master...Randgalt:wip-grpc> > > >> > >> Issues: > >> Writing a client, even with gRPC, will require some work. Sessions have > to be maintained, watchers have to be maintained, etc. > >> Currently, Jute is deeply embedded in ZooKeeper. The proof of concept > has to emulate Jute byte buffers. Ideally, this will be abstracted so that > only records could be used so that the gRPC connection doesn't have to keep > marshalling/unmarshalling byte buffers > >> I don't know enough about the gRPC client/server implementations to > know if it will meet the needs of ZooKeeper. Anyone have experience here? > >> I haven't completely thought through how much work it will take to > write useful clients. As I've shown with the proof of concept simple ZK > CRUD db operations work well. I need to spend time writing a recipe such as > Leader Election to see how much work is required. > >> I'm not sure how things like SASL and reconfig would work with gRPC > >> > >> -Jordan > >
