The main issue is that you can overload it with reads (writes are always going to be slow in such a system). To deal with this, ZK is adding read slaves which do not participate in Paxos.
The main issue is that you can overload it with reads (writes are always going to be slow in such a system). To deal with this, ZK is adding read slaves which do not participate in Paxos.
The point I was trying to make is that, if you're just doing leader election for a single service (so you essentially have one key, probably 1KB of state), then spawning up even 3 JVMs is difficult to justify. That's Go's sweet spot for me - small daemons that you would otherwise be tempted to write in C.
I am excited by the new code in Zookeeper trunk which allows dynamic cluster reconfiguration; along with observers then you can have one zookeeper instance per machine if you want to, and the cluster can self-heal. But you still wouldn't want to do that unless you were actually sharing a non-trivial amount of data :-)
Well, you could compile to native code instead.
Additionally you have,
- Avian (http://oss.readytalk.com/avian/)
- Codename One (http://www.codenameone.com/), just for mobiles
- Aonix (http://www.atego.com/products/aonix-perc/)
- WebSphere Real Time (http://www-03.ibm.com/software/products/us/en/real-time)
- Jikes RVM (http://jikesrvm.org/)
Are you referring to observers ? They've been in ZK since 3.3.*, if not before.
edit: actually you mentioned they're _read_ slaves, whereas you can write to zookeeper observers (they just don't participate in elections, which is as you said)