-
Notifications
You must be signed in to change notification settings - Fork 7.3k
ZOOKEEPER-4747: Add synchronous sync to ease synchronous call chains #2068
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2708,6 +2708,31 @@ public void getEphemerals(AsyncCallback.EphemeralsCallback cb, Object ctx) { | |
| getEphemerals("/", cb, ctx); | ||
| } | ||
|
|
||
| /** | ||
| * Synchronous sync. Flushes channel between process and leader. | ||
| * | ||
| * @param path the given path | ||
| * @throws KeeperException If the server signals an error with a non-zero error code | ||
| * @throws InterruptedException If the server transaction is interrupted. | ||
| * @throws IllegalArgumentException if an invalid path is specified | ||
| */ | ||
| public void sync(final String path) throws KeeperException, InterruptedException { | ||
| final String clientPath = path; | ||
| PathUtils.validatePath(clientPath); | ||
|
|
||
| final String serverPath = prependChroot(clientPath); | ||
|
|
||
| RequestHeader h = new RequestHeader(); | ||
| h.setType(ZooDefs.OpCode.sync); | ||
| SyncRequest request = new SyncRequest(); | ||
| SyncResponse response = new SyncResponse(); | ||
| request.setPath(serverPath); | ||
|
Comment on lines
+2720
to
+2729
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It would be cleaner to refactor this to share code with the asynchronous version, since everything up to here is identical.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess it may not worth the effort.
A little duplication probably be a good here. |
||
| ReplyHeader r = cnxn.submitRequest(h, request, response, null); | ||
| if (r.getErr() != 0) { | ||
| throw KeeperException.create(KeeperException.Code.get(r.getErr()), clientPath); | ||
|
Comment on lines
+2730
to
+2732
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When an asynchronous method and a synchronous version are available, I feel like the easiest implementation of a synchronous version is something like:
This implementation might be doing something like that, but it's not obvious as written. If it's doing anything like that, the details might be obscured inside the submitRequest method. That might make this implementation less readable, and therefore harder to maintain. I think using Futures are more intuitive, if it's not too difficult to implement that way. You actually have a version like this in the test code in this PR. I'm not sure why that couldn't be the implementation here.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I am positive to using future internally for synchronous api. This should also solve your above concern about "identical code". But I found ZOOKEEPER-4749 in investigation, may be we should wait a minute. I don't want to handle it specially for sole this api. |
||
| } | ||
| } | ||
|
|
||
| /** | ||
| * Asynchronous sync. Flushes channel between process and leader. | ||
| * @param path | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the path argument even needed? My understanding is that the path has no effect.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeh, it does no take effect since day one of
sync. ZOOKEEPER-3414(#1187) proposed to error on no node. I think we should keep it until we have conclusion about that and semantics of sync path. Otherwise, if ZOOKEEPER-3414 is delivered in future, thesyncwith no path(default to "/") could fail due tochrootis not required to be existed in data tree. At the least, I think it is a separate issue and we should keep consistent between two versions ofsync.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand the argument for keeping it consistent, but I also know it's a pain to have API churn. So, it'd be nice for a decision to be reached and to add the new method in just once, rather than add it, and have to change it (or add a confusing overloaded version) later.