Andrew Purtell wrote: > > Ya, I wondered about that too, esp given he mentions > > > > "(yes I'm aware that you can run Zookeeper in single server > > mode from a single JAR file)" > > > > and Noah's stack requires (granted we require java): > > > > Ruby > > EventMachine/Sinatra/Ohm > > Redis > > > > Patrick > > That was the dumbest thing I've read in a few weeks. > > Just managing Redis persistence is as or more complex than using ZooKeeper. >
Don't be too quick to dismiss this - I think there are useful bits to be gleaned. The two big ones that come to mind for me are: 1. There's a lot of fear and hesitation around building (high performance, critical) infrastructure around Java. 2. Interfaces are very important. #1 is mostly PR, but also reflects that operating stuff in a JVM adds a layer of abstraction that is pretty opaque. Maybe more emphasis on zookeeper's real-world performance numbers, case studies, and/or debugging tools is in order. Personally, I also find the signal to noise ratio of the zookeeper logging to be very high. 'ruok' generates INFO and WARNING log entries on my (old, 3.1.1) install, for example. #2 is something that I think is worth tackling with reference client/API implementations above and beyond java. Really, the only truly supported, asyncronous APIs for zookeeper are Java and C (I'm not counting the stuff wrapped around the C client), and that limits the client audience significantly - I think one of the things that Noah gets right is having a REST interface. </$.02> -- [email protected] (>^-^)>
