hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Client-Server wire compatibility?
Date Fri, 06 Mar 2015 20:18:34 GMT
On Thu, Mar 5, 2015 at 5:19 PM, Enis Söztutar <enis@apache.org> wrote:

> The way some of the RPC's are done today is kind of negotiation
> after-the-fact. So the client does an RPC, it can fail with
> NoSuchMethodException, in which case the client should fallback if the
> operation is supported in the old version (like create table). In some
> cases where we add a new field in the PB for requests or responses, we
> always add it as optional, and check the existence of that field to do the
> new behavior or old behavior. In this sense, it is not negotiation per-se,
> but a feature-based graceful fallback.
> Coming to the specifics, I think what to do for Procv2 based DDL statements
> can be achieved using a similar strategy. For example, the create table
> request is sent, and a response returned back to the client. The create
> table request is handled after the response is returned back to the client,
> and the client just waits there for observing the "side affects" of the
> create table statement execution. If for example we do procv2 based create
> table, the create table response can optionally return the proc_id to the
> client in the same response. If it is a new client talking to the new
> server the proc_id will be there, so the client can safely call proc_v2
> related RPC endpoints. If the returned response does not contain proc_id,
> then it is an old server, so it should do what it does today. This enables
> to have a client to be BC with old masters and new masters. If the client
> is old, even if the new master returns a proc_id, the client will ignore
> it.


So we make no promises for clients being able to go back in time so fine if
the Admin function fails because old server; better if it just worked but
that is nice-to-have.

For the clients hosted in server talking to old server:

We could retrofit support for generic feature negotiation (in a BC way) and
add appropriate fallbacks if wanted facility is missing. We'd be
hand-crafting this new stuff atop the custom hadoop rpc that serves as our
current transport, and we would do the testing for this generic facility to
make sure it works for those occasions it is needed.

Or we could figure what subset of server-hosted client function needs the
treatment Enis describes above to get us back our rolling upgrade inside a
minor version as per our semvar promises. Does server-hosted client do any
Admin functions?  If not, thats a set of functions we'd NOT need to make
BC. Is all that is needed a bit of Scan, Delete and Put?  If P, D and S
will do, then we need to do the above special treatment for this subset of
calls ensuring new versions can always work with old servers always.

The latter could get unmaintainable if the surface area is broad and in
flux but mayhaps we can cut it down (I've not done the research).


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message