You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kudu.apache.org by "Todd Lipcon (Code Review)" <ge...@cloudera.org> on 2016/02/19 03:18:38 UTC
[kudu-CR] rpc: add negotiation of RPC-layer feature flags
Hello Dan Burkert, Jean-Daniel Cryans,
I'd like you to do a code review. Please visit
http://gerrit.cloudera.org:8080/2238
to review the following change.
Change subject: rpc: add negotiation of RPC-layer feature flags
......................................................................
rpc: add negotiation of RPC-layer feature flags
This extends the RPC system with a simple mechanism for advertising
a set of supported feature flags during connection establishment.
The list of supported features is hard-coded in the build, and is
used in lieu of a version number in order to communicate which
capabilities an RPC client or server supports.
There are several advantages of feature flags over version numbers:
- since we have both a Java and C++ client, this allows us to add
features in different orders, or decide to not support a feature
at all in one client or the other. For example, the C++ client
is likely to gain support for a shared-memory transport long before
the Java one.
- this allows much more flexibility in backporting RPC system features
across versions. For example, if we introduce feature 'A' in Kudu
2.0, and feature 'B' in Kudu 2.1, we are still able to selectively
backport 'B' without 'A' to Kudu 1.5.
- currently, the set of supported features is determined only by
code-level support, but we could later decide to conditionally
enable features based on configuration or machine capability.
The most reasonable place to add the exchange of feature flags was
to add them to the existing SASL negotiation messages, where we
already had an unused 'version' field. The naming is not great, given
that the SASL negotiation is now negotiating more than just SASL,
but I didn't want to feature-creep into a wholesale rename or refactor,
and adding a separate negotiation phase would waste an extra round trip
as well as be difficult to add compatibly.
Change-Id: Ib9c7fdf03920496c12d92eba23d8d4f7b7cb8fc5
---
M src/kudu/rpc/constants.cc
M src/kudu/rpc/constants.h
M src/kudu/rpc/negotiation.h
M src/kudu/rpc/rpc_header.proto
M src/kudu/rpc/sasl_client.cc
M src/kudu/rpc/sasl_client.h
M src/kudu/rpc/sasl_rpc-test.cc
M src/kudu/rpc/sasl_server.cc
M src/kudu/rpc/sasl_server.h
9 files changed, 97 insertions(+), 2 deletions(-)
git pull ssh://gerrit.cloudera.org:29418/kudu refs/changes/38/2238/1
--
To view, visit http://gerrit.cloudera.org:8080/2238
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ib9c7fdf03920496c12d92eba23d8d4f7b7cb8fc5
Gerrit-PatchSet: 1
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Todd Lipcon <to...@apache.org>
Gerrit-Reviewer: Dan Burkert <da...@cloudera.com>
Gerrit-Reviewer: Jean-Daniel Cryans