Optimization to reduce write load to ZK #7
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.



Right now, all executors send updates to ZK. With clusters having many nodes or running many containers that are constantly in a state of flux, this creates a lot of write pressure on zk. This PR addresses this issue by implementing a
RemoteNodeDataStoreimplementation in the executor with the following behaviour:remoteUpdateModeinExecutorOptionsthat can be set toSTOREorRPC(default)STOREis the legacy behaviour and it will lead the executor to send updates via ZKRPCmode (the default behaviour going forward) will lead to updates being sent over HTTP to the leader controller via the existingcommunicator. In case update fails or there is an exception in the update path, updates will be sent via the store (ZK)Calls to
removeNodeswill lead to an error and calls tonodeswill be routed via ZK.The Guice Module has been updated to create appropriate objects.