questions regarding the java ZooKeeper client and its asynchronous, multiop, asynchronous multiop apis
When dealing with leadership initialization and group membership changes to
my system, I'm looking into options for doing many zookeeper operations
quickly. I'm using the java org.apache.zookeeper.ZooKeeper client. Both the
client and ensemble are using zookeeper 3.4.9. Currently, our system
entirely uses the synchronous apis but this can be problematic as the
number of zookeeper operations grows. I've been considering the
asynchronous apis as well as the synchronous and asynchronous multiop apis.
To get around the 1MB "jute.maxbuffer" limitation on the multiop, I've also
looked into splitting the operations into various multiop batch sizes for
the synchronous and asynchronous multiop apis as an alternative to having
one huge request.
I've got a few questions:
1. How ready is multiop? Have people been using it in production?
2. Does all of this sound accurate?
From what I understand, multiop is truly a transaction. Either all
operations commit or all abort.
a. With the synchronous multiop api, either a List<OpResult> is returned
containing the successful results or a KeeperException is thrown in which
you can call KeeperException.getResults() to spot the individual operation
that caused the abort (it's the operation corresponding to the ErrorResult).
b. With the asynchronous multiop api, you can spot the individual
operation that caused the abort by looking up the operation corresponding
to the ErrorResult in the List<OpResult> passed into the MultiCallback.
3. For the asynchronous multiop api, what is the relation, if any, between
the return code passed to the MultiCallback and the error codes of the
ErrorResults in the List<OpResult> passed into the MultiCallback?
4. In terms of reads, I looked over the APIs and only found individual
synchronous and asynchronous reads. Is there no way to batch reads in a
5. Is there any config to control client memory usage? For instance, this
can be in the form of bounding the number of in-flight asynchronous