read all the stat info, even when it exceeds 2048 bytes. #7
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ivmaykov
pushed a commit
to ivmaykov/zookeeper
that referenced
this pull request
Oct 15, 2018
Summary:
Here's a checkpoint of the Persistent Recursive Watch code. This diff contains all the code I think required for both client and server side. I've yet to look at the C client. I've yet to run any unit tests or create new tests. I thought I get this out there early to get some feedback to make sure I'm going in the right direction.
I extended the ZooKeeper API to add 3 methods (there are also async versions):
+ createRWatch(path, type)
This creates a recursive watch on the specified path. Data and/or child event types are supported. I decided exists isn't necessary since registering a recursive watch at a path where there's no node is equivalent to an Exists watch. Let me know if I missed anything here. This watch persists until a corresponding deleteRWatch call is made or the client shuts down. The create request sends the most recent zxid known to the client along with a path where the watch is to be registered. The server will fire an event for each node under path that has a cxid or mxid greater than the most recent zxid seen by the client.
+deleteRWatch(path, type)
This deletes a previously registered recursive watch at the specified path.
+getRWatches(type)
Get list of registered recursive watches of the given type(s).
General semantics changes. I decided that it was easier to always fire an event for matching recursive watches and guarantee that no more than one event per-type is fired. The client will forward the even to all registered watchers both recursive and non-recursive. Non-recursive watch event handlers will deregister itself upon the first event instance.
Test Plan:
I. Add all async API invocation tests to AsyncOpTests.
II. Following tests added to RecursieWatcherTest:
1.Synchronous Create recursive watch: data, child, data+child
2.Synchronous Delete recursive watch: data, child, data+child
3.Synchronous Get recursive watch list: data, child, data+child
4.Create and receive recursive watch notification:
4.1 For data notifications on node, on child-node
4.2 For children notifications on node, on child-node
5.Delete recursive watch and observe no notification
5.1 For data notifications on node, on child-node
6.Create multiple recursive notifications on descendants:
6.1 For data notification only one notification is sent, but all
watchers notified.
7.Create recursive watch, then a normal watch on a child-node.
7.1 Observe data watch received on both watchers on first notification.
7.2 Observe data watch received on only recursive watch.
8.Create recursive watch, then a normal watch on a child-node.
8.1 Force reconnect. Then observe watches are re-set.
8.1.2 Observe success on per 7.1 and 7.2
9.Create parallel recursive watch on the same node from 2 clients per
test apache#4.
9.1 Observe per apache#7.1 on both clients.
9.2 Observe per apache#7.2 on both clients.
10.Test catch-up condition:
10.1 Create /a/b znode and 2 clients: client-1 and client-2
10.2 Register rwatch on /a/b on client-1
10.3 Shutdown client-1
10.4 Update /a/b znode from client-2
10.5 Start client-1 with autoResetWatch set to true.
10.6 Observe client-1 receive Data notification for /a/b
All tests above passed.
Reviewers: vishal, jays, thawan
Reviewed By: jays
CC: zeus-dev@lists
Differential Revision: https://phabricator.fb.com/D433398
git-svn-id: svn+ssh://tubbs/svnhive/hadoop/trunk/VENDOR.zookeeper/fb-trunk@24641 e7acf4d4-3532-417f-9e73-7a9ae25a1f51
asfgit
pushed a commit
that referenced
this pull request
Jan 25, 2019
This is a master branch version of: #654 The previous PR was for branch 3.5, and couldn't be merged as that branch is closed for new features. The Zookeeper libraries currently allow you to set up your SSL Context via system properties such as "zookeeper.ssl.keyStore.location" in the X509Util. This covers most simple use cases, where users have software keystores on their harddrive. There are, however, a few additional scenarios that this doesn't cover. Two possible ones would be: 1. The user has a hardware keystore, loaded in using PKCS11 or something similar. 2. The user has no access to the software keystore, but can retrieve an already-constructed SSLContext from their container. For this, I would propose that the X509Util be extended to allow a user to set a property "zookeeper.ssl.client.context" to provide a class which supplies a custom SSL context. This gives a lot more flexibility to the ZK client, and allows the user to construct the SSLContext in whatever way they please (which also future proofs the implementation somewhat). I added a few simple tests to this class around setting the SSLContext, and setting an invalid one. I'm not testing the actual functionality of the SSLContext, etc. Author: Alex Rankin <davelister@gmail.com> Author: Alex Rankin <alex.rankin@mastercard.com> Reviewers: andor@apache.org Closes #728 from arankin-irl/ZOOKEEPER-3160 and squashes the following commits: a20c62f [Alex Rankin] Merge branch 'master' into ZOOKEEPER-3160 5a9b8fc [Alex Rankin] Merge pull request #7 from apache/master 3c3dfdd [Alex Rankin] Re-ordering imports. 69e0b6c [Alex Rankin] Updating custom SSLContext supplier with review comments 874529b [Alex Rankin] Using supplier interface instead of custom interface, and renaming property ec27260 [Alex Rankin] Merge branch 'master' into ZOOKEEPER-3160 75a010e [Alex Rankin] Merge pull request #6 from apache/master 838f61c [Alex Rankin] Merge branch 'master' into ZOOKEEPER-3160 f85d7e5 [Alex Rankin] Merge pull request #5 from apache/master 31d8dd5 [Alex Rankin] Extracting SSLContext creation from config to new method. 400839a [Alex Rankin] Adding ability to specify custom SSLContext for client 7ae7485 [Alex Rankin] Merge pull request #4 from apache/master
ztzg
pushed a commit
to ztzg/zookeeper
that referenced
this pull request
Nov 20, 2019
Implemented the Leader Election recipe
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
More details in https://issues.apache.org/jira/browse/ZOOKEEPER-1826