[
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035623#comment-13035623
]
Marshall McMullen commented on ZOOKEEPER-965:
---------------------------------------------
Ted, others...
I've just pushed a commit to Ted's private branch to fix a few minor error
handling issues I discovered while integrating this into our own product.
Details below from my commit message:
ZOOKEEPER-965 - Fix error code handling.
Error codes were not propagating out from the server properly.
The original design dictated that if the multi op fails, then
all the entries in the multi result would be an error result. The
error code in that error result would be used to determine which
op failed in the multi-op. Specifically, error codes in the multi result:
0: The op would have succeeded had the entire multi op not failed
ZRUNTIMEINCONSISTENCY: The op was AFTER the failing op and was aborted
Anything else: The real error code for the op that caused the entire
multi op to fail (this is the one that is thrown as well).
Also, discovered another error code issue. If a op in the multi
op is after the failing op, it still ran through PrepRequestProcessor.
That was confusing (and unecessary) as we know the entire multi op
is going to fail. Modified it to abort all ops after a failing op
to avoid unecessary work and also to avoid confusion in the log files.
Also added some unit tests to verify all above described changes.
> Need a multi-update command to allow multiple znodes to be updated safely
> -------------------------------------------------------------------------
>
> Key: ZOOKEEPER-965
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-965
> Project: ZooKeeper
> Issue Type: Bug
> Affects Versions: 3.3.3
> Reporter: Ted Dunning
> Assignee: Ted Dunning
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-965.patch, ZOOKEEPER-965.patch,
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch,
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch,
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch,
> ZOOKEEPER-965.patch
>
>
> The basic idea is to have a single method called "multi" that will accept a
> list of create, delete, update or check objects each of which has a desired
> version or file state in the case of create. If all of the version and
> existence constraints can be satisfied, then all updates will be done
> atomically.
> Two API styles have been suggested. One has a list as above and the other
> style has a "Transaction" that allows builder-like methods to build a set of
> updates and a commit method to finalize the transaction. This can trivially
> be reduced to the first kind of API so the list based API style should be
> considered the primitive and the builder style should be implemented as
> syntactic sugar.
> The total size of all the data in all updates and creates in a single
> transaction should be limited to 1MB.
> Implementation-wise this capability can be done using standard ZK internals.
> The changes include:
> - update to ZK clients to all the new call
> - additional wire level request
> - on the server, in the code that converts transactions to idempotent form,
> the code should be slightly extended to convert a list of operations to
> idempotent form.
> - on the client, a down-rev server that rejects the multi-update should be
> detected gracefully and an informative exception should be thrown.
> To facilitate shared development, I have established a github repository at
> https://github.com/tdunning/zookeeper and am happy to extend committer
> status to anyone who agrees to donate their code back to Apache. The final
> patch will be attached to this bug as normal.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
