Awesome! Is there any design docs and related code to read? I'm not very sure. The proxy is more like a client to ZooKeeper. I'm thinking in terms of ZK server RPC api.
- Hongchao Deng > Date: Mon, 13 Apr 2015 11:57:45 -0500 > From: [email protected] > To: [email protected]; [email protected] > Subject: RE: design thoughts: node TTLs > > Hongchao, as I mentioned before I wrote an RPC proxy for Curator that exposes > all the ZooKeeper APIs and all the Curator APIs and recipes. This proxy uses > Thrift and writing clients is actually very easy and natural as Thrift > generates native APIs. > > http://curator.apache.org/curator-x-rpc/index.html > > -Jordan > > > > On April 13, 2015 at 11:55:12 AM, Hongchao Deng ([email protected]) > wrote: > > Hi Jordan, I can share some thoughts on this. > I think it's not easy to write client in other languages because the client > connection is stateful. It contains information of watches, session, etc. > Even if the server exposes RPC, REST, it's still a lot of work to write a > client. I think making client stateless requires some redesign, which is also > a lot of work.. Sorry no answer here.. > - Hongchao Deng > > > Date: Mon, 13 Apr 2015 10:35:49 -0500 > > From: [email protected] > > To: [email protected]; [email protected] > > CC: [email protected]; [email protected] > > Subject: Re: design thoughts: node TTLs > > > > How does the current REST code handle watches and background notifications? > > Are clients required to poll periodically? This is really RPC and REST is > > not ideal for RPC. So, as I mentioned before, I think the ZK team should > > consider a real RPC system like Thrift instead of REST. > > > > -Jordan > > > > > > > > On April 11, 2015 at 1:33:03 PM, Patrick Hunt ([email protected]) wrote: > > > > We pack quite a bit of functionality in our client side libraries. That's > > probably one of the main things you'll noticed if you try to use REST. But > > then if your use case is primarily configuration, or something that doesn't > > > > require sessions then the current REST support should be more than > > sufficient. What are the other systems doing that we are currently not > > doing wrt API support? > > > > I'd think that taking our current rest contrib, updating the dependencies, > > and deploying as part of the embedded jetty would work well with minimal > > effort. > > > > Patrick > > > > On Sat, Apr 11, 2015 at 9:22 AM, Camille Fournier <[email protected]> > > wrote: > > > > > I agree that they have to write clients that do work, but there is > > > clearly > > > a desire and willingness out there to do that work in exchange for a more > > > > > > "obvious" way of interacting. So supporting it should be something that > > > we > > > consider if the users of such systems want the option. > > > > > > On Sat, Apr 11, 2015 at 12:07 PM, Jordan Zimmerman < > > > [email protected]> wrote: > > > > > > > REST has issues for end users. They will still have to write clients > > > > and > > > > do a lot of extra work. REST support is good in most languages but > > > > having > > > > native support is superior. That’s why I choose Thrift for the > > > > CuratorRPC > > > > Proxy. > > > > > > > > -Jordan > > > > > > > > > > > > On April 10, 2015 at 9:32:47 PM, Michi Mutsuzaki > > > > ([email protected]) > > > > wrote: > > > > > > > > Yeah it's quite painful to manage another set of processes just for > > > > proxying requests. I'd definitely use this if I can run it embedded in > > > > the ZooKeeper process. I'm very excited about the idea of being able > > > > to use curl to look at what's in ZooKeeper :) > > > > > > > > On Fri, Apr 10, 2015 at 6:03 PM, Patrick Hunt <[email protected]> wrote: > > > > > > > > > Here's the spec and readme from contrib/rest: > > > > > > > > > > > > > > > > > http://svn.apache.org/viewvc/zookeeper/trunk/src/contrib/rest/SPEC.txt?view=markup > > > > > > > > > > > > > > > http://svn.apache.org/viewvc/zookeeper/trunk/src/contrib/rest/README.txt?view=markup > > > > > > > > > > > > > The current implementation is a standalone proxy. It's not embedded > > > > > in > > > zk > > > > > itself. That might be part of the reason. > > > > > > > > > > Patrick > > > > > > > > > > On Fri, Apr 10, 2015 at 4:43 PM, Camille Fournier > > > > > <[email protected]> > > > > > wrote: > > > > > > > > > >> Forgive me for not reading the code, can you share in more detail > > > > >> what > > > > the > > > > >> existing REST proxy provides? I'm curious why people are jumping to > > > use > > > > >> etcd because of ease of use w/http access if we already have > > > > >> something > > > > that > > > > >> works? > > > > >> > > > > >> On Fri, Apr 10, 2015 at 7:28 PM, Patrick Hunt <[email protected]> > > > wrote: > > > > >> > > > > >> > There's the REST work in contrib. Both Andrei and I worked on that > > > > >> > > > > - I > > > > >> did > > > > >> > the basic support and Andrei added sessions and heartbeating among > > > > >> > > > > > other > > > > >> > improvements. > > > > >> > > > > > >> > Now that 3.5 has embedded Jetty it should be much simpler to run > > > REST > > > > as > > > > >> > part of the ZK service itself. When the original proxy work was > > > > >> > done > > > > >> Jetty > > > > >> > was not yet part of ZK. > > > > >> > > > > > >> > Patrick > > > > >> > > > > > >> > On Thu, Apr 9, 2015 at 10:20 AM, Jordan Zimmerman < > > > > >> > [email protected]> wrote: > > > > >> > > > > > >> >> Since Curator is now Apache and I'm no longer at Netflix, I don't > > > > >> >> > > > > follow > > > > >> >> Netflix messages very much. Sorry about that. > > > > >> >> > > > > >> >> -Jordan > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> On April 9, 2015 at 12:15:02 PM, Camille Fournier ( > > > > [email protected]) > > > > >> >> wrote: > > > > >> >> > > > > >> >> Thanks Jordan! I actually asked on Twitter whether Netflix had > > > > anything > > > > >> >> but > > > > >> >> didn't get a clear answer. > > > > >> >> > > > > >> >> On Thu, Apr 9, 2015 at 11:22 AM, Jordan Zimmerman < > > > > >> >> [email protected]> wrote: > > > > >> >> > > > > >> >> > FYI > > > > >> >> > > > > > >> >> > Curator now has a Thrift-based proxy that has all the ZK APIs > > > > exposed > > > > >> as > > > > >> >> > well as Curator's added APIs and recipes: > > > > >> >> > > > > > >> >> > http://curator.apache.org/curator-x-rpc/index.html > > > > >> >> > > > > > >> >> > -Jordan > > > > >> >> > > > > > >> >> > On April 8, 2015 at 2:09:33 PM, Camille Fournier ( > > > > [email protected]) > > > > >> >> > wrote: > > > > >> >> > > > > > >> >> > All, > > > > >> >> > > > > > >> >> > I've been doing a bit of research on etcd as part of work for > > > > >> >> > an > > > > >> >> upcoming > > > > >> >> > talk, and it has gotten me thinking about what it would take to > > > > >> >> > > > > > create > > > > >> >> an > > > > >> >> > http version of ZK for certain operations. For many operations > > > you > > > > >> could > > > > >> >> > put an http proxy in front of ZK to translate, even > > > > >> >> > implementing > > > > the > > > > >> >> > "long-poll-style" watch operation to some extent. But it would > > > > >> >> > be > > > > very > > > > >> >> > hard > > > > >> >> > to do a temporary node via a proxy without a lot of proxy > > > failover > > > > >> >> > complexity. > > > > >> >> > > > > > >> >> > As a bit of background, if you want to do an "ephemeral" node > > > > >> >> > in > > > > etcd, > > > > >> >> you > > > > >> >> > basically create a key with a TTL. Unless the key is updated > > > with a > > > > >> new > > > > >> >> > TTL, the key will auto-expire when the TTL is reached. Now, I > > > have > > > > a > > > > >> lot > > > > >> >> > of > > > > >> >> > thoughts about this (seems like you have to implement > > > > >> >> > heartbeats > > > > via > > > > >> >> http > > > > >> >> > to truly mimic ephemeral nodes which may not be as simple as > > > > >> >> > all > > > > this > > > > >> >> http > > > > >> >> > sounds), but I do think that if there is appetite for easy http > > > > >> >> > > > > > access > > > > >> >> for > > > > >> >> > consensus systems we should at least take the time to think > > > > >> >> > about > > > > what > > > > >> >> it > > > > >> >> > would take for us to provide this. In particular, I think we'd > > > > have to > > > > >> >> > make > > > > >> >> > it possible to create a node with a TTL that is not tied to a > > > > >> particular > > > > >> >> > session. > > > > >> >> > > > > > >> >> > Curious to see if anyone has any thoughts on this. It seems > > > > >> >> > like > > > a > > > > bit > > > > >> >> of > > > > >> >> > a > > > > >> >> > shame that ZK, which is a good battle-tested system, is > > > frequently > > > > >> being > > > > >> >> > passed-over these days because of the complexity of clients, > > > > >> >> > and > > > > the > > > > >> >> fact > > > > >> >> > that it is really pretty damn hard to do a client impl in > > > > >> >> > certain > > > > >> >> > languages > > > > >> >> > (Ruby is the notable one I've heard). > > > > >> >> > > > > > >> >> > Best, > > > > >> >> > C > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > >> > > > > > >> > > > > > >> > > > > > > >
