Jetcd: Java client library for etcd
blog.justinsb.com
blog.justinsb.com
I haven't seen Apache's HttpAsyncClient used in many places. The API looks sane enough. I'm not sure how stable it is compared to Netty; performance seems to be less of an issue given that it uses NIO.
How's jetcd on thread-safety?
I'd be interested to cook up a version that uses Netty or Vert.x, although there's not quite an excuse to do so...
- time to live keys
- persistence to disk
- TLS support for client and backendThe 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)
>
> The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.