I've now got a working stand-alone 'proxy' that acts as a Thrift server and a ZK client. Is this something you guys would want/accept as a contrib module? I appreciate that you already have SWIG and FUSE bindings, but I think the Thrift interface makes more sense in environments where [most] other services are already exposed using Thrift.
At present the code is not hugely nice, as it has to convert between Thrift-generated objects and Jute-generated ones; if you did switch to using Thrift RPC for ZK's serialisation layer it'd make this a lot more tidy. Also, it doesn't support watches at the minute, although I can think of several ways this could be done if needed (I don't think we actually need them for what we're going to be using the Thrift interface for). - Chris On Wed, Jul 16, 2008 at 4:47 AM, Benjamin Reed <[EMAIL PROTECTED]> wrote: > Hi Chris, > > We have talked about using Thrift for our serialization layer (I thought > we had a Jira opened for it, but I cannot find it). Thrift RPC is a > different story. You would lose watch callbacks. I think it would also > be hard to support sessions and thus ephemeral nodes. Finally, your > client and server throughput would be quite low since clients wouldn't > be able to pipeline requests (it appears you can only have one request > outstanding at a time) and servers have to dedicate a thread to service > a request. > > ZooKeeper clients are more than simple RPC dispatchers they also do > session maintenance and completion processing, so you need something a > bit more sophisticated at the client. > > I assume you want this to get bindings for other languages. We have SWIG > and FUSE bindings for this. > > If you really want thrift, I think there is a combo solution: implement > a standalone service, thrift server and zk client, and run it on each > ZooKeeper server. > > ben > > Chris Smith wrote: >> >> Hi, >> >> I'm currently thinking about implementing a Thrift interface for >> ZooKeeper, and wanted to get some opinions on it before I start. I can >> basically see two possible ways to implement it: >> >> * A standalone service which implements both a ZooKeeper client and a >> Thrift server, and basically acts as a proxy between the two >> * Integrate the Thrift server with the ZooKeeper server, so that ZK >> servers themselves handle the Thrift connections >> >> I think the former is probably nicer from a development stand-point, >> but the latter seems better from an end-user stand-point. Has anyone >> else thought about doing this (or actually done it!), and does anyone >> have any preferences/comments with regard to the above options? >> >> Cheers, >> >> Chris Smith >> > >
