Hey everyone. 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 multiop? 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 requests. - Onur
