Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # dev >> Handling protocol versions


+
Devaraj Das 2012-07-31, 00:47
+
Jimmy Xiang 2012-07-31, 03:09
+
Ted Yu 2012-07-31, 03:11
+
Ted Yu 2012-07-31, 21:50
+
Stack 2012-08-01, 08:41
+
Todd Lipcon 2012-08-01, 18:04
+
Andrew Purtell 2012-08-01, 19:39
+
Devaraj Das 2012-08-03, 18:40
+
Stack 2012-12-27, 20:05
+
Jimmy Xiang 2012-12-27, 21:13
Copy link to this message
-
Re: Handling protocol versions
I think what Devaraj describes is a valid use case, and I am sure we will
need it a few times. However, I suspect each of these might be unique, and
we have to deal with how to handle backwards-forwards compat from the
client differently (image META moving to zk, after 0.96). So we cannot
easily generalize, and we may still have to drop support for features
gradually.

If we still keep the version, do we bump it every time a parameter is added
to a method, or only when a new method is added? It does not sound very
maintainable.

Not knowing much about the recent changes, why don't we go full PB, and
define actual rpc methods as services? (as in
https://developers.google.com/protocol-buffers/docs/proto#services)
On Thu, Dec 27, 2012 at 1:13 PM, Jimmy Xiang <[EMAIL PROTECTED]> wrote:

> +1 for removing VersionedProtocol and SignatureProtocol
> +0 for VersionedService/ProtocolDescriptor
>
> If we do have VersionedService/ProtocolDesscriptor, it will most likely be
> used in some
> mixed environment (most likely, new client and mixed versions of HBase
> servers, since old client doesn't
> know any new feature, old client doesn't assume an existing feature will be
> gone in the future either).
>
> With PB,  I think we are going to support a rolling-upgrade path.  That
> means, some mixed
> versions of HBase servers can be compatible. For enterprise, I think it is
> not that hard to
> maintain compatible HBase clusters.  So I don't think it is absolutely
> needed.
>
> Thanks,
> Jimmy
>
> On Thu, Dec 27, 2012 at 12:05 PM, Stack <[EMAIL PROTECTED]> wrote:
>
> > So, picking up this thread again because I'm working on
> > https://issues.apache.org/jira/browse/HBASE-6521 "
> > Address the handling of multiple versions of a protocol"Address the
> > handling of multiple versions of a protocol", the original question was
> >  two-fold as I read it.
> >
> > 1. Should we keep VersionedProtocol.
> > 2. How does a client figure if a server supports a particular capability
> >
> > On question 1:
> >
> > VersionedProtocol [1] does two things.  It returns the server version of
> > the protocol and separately, a "ProtocolSignature" Writable which allows
> > you get a 'hash' of the server's protocol method signatures.   There is
> an
> > implication that the server will give out different versions of the
> > protocol dependent on what version the client volunteers (not the case)
> and
> > it is implied that the client does something with these method hash
> > signatures.  It doesn't.
> >
> > So, VP is a Writable that returns Writables we don't make use of
> implying a
> > functionality unrealized.
> >
> > Thats how I read it.  Objections? [3]
> >
> > It sounds like at least ProtocolSignature can go.  If we did want to go
> the
> > route ProtocolSignature implies, we should probably do the native
> protobuf
> > thing and make use of ServiceDescriptors, protobuf descriptions of what a
> > protobuf Service exposes [2].
> >
> > That leaves the VPs return of the server protocol version as all that
> > remains 'useful'.
> >
> > But is it? Is version going to be useful going forward?  If we lean on
> > version, clients will have to keep a registry of versions to available
> > methods.  Or ask the server what it has and somehow sort though the
> return
> > to figure what it can and cannot make sense of by method.  Sounds like a
> > bunch of work.
> >
> > At a minimum, VP will have to be protobuf'd so it is going to have to
> > change.  And we should probably add a bit more info to the return since
> we
> > are going to the trouble of an RPC anyways.
> >
> > This serves as a lead in to question 2:
> >
> > Protobuf as is helps in the case where an ipc takes an extra parameter or
> > adds extra info to the return; the majority of the evolutions that will
> be
> > happening in the ipc interface.  But what to do about the scenario
> Devaraj
> > outlines at the head of the thread where we have shipped a method that
> > causes the server to OOME in production or we add a method to the server
+
Stack 2012-12-28, 03:11
+
Stack 2013-01-02, 00:44
+
Elliott Clark 2013-01-02, 22:34
+
Stack 2013-01-07, 21:15
+
Devaraj Das 2012-12-28, 09:31
+
Stack 2012-12-28, 16:59
+
Devaraj Das 2012-12-28, 17:22