hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elliott Clark <ecl...@apache.org>
Subject Re: Handling protocol versions
Date Wed, 02 Jan 2013 22:34:38 GMT
Removing the versioning altogether seems good.  That leads to much less
coupling between the client and the server.

I would vote to use BlockingInterface (to replace our versioned protocol
class) everywhere and just write our own rpc/ipc.  Stack walked me through
some of the code that is needed for using all of the Protobuf Service and
Protobuf Blocking Channels; That route seems to have lots of it's own
cruft.  So if we're going to have a clean up, we shouldn't start out with
something knowing the result will be crufty.

Additionally we should move the exception responses into either the header
or the body.  As it currently stands having to conditionally cast the next
message into either a response or an error just seems like we're
re-implementing protobuf's optional.

On Tue, Jan 1, 2013 at 4:44 PM, Stack <stack@duboce.net> wrote:

> On Thu, Dec 27, 2012 at 7:11 PM, Stack <stack@duboce.net> wrote:
> >  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)
> >>
> >>
> > I thought about it.  It has some nice facility that comes for free.  For
> > example, you can get an aforementioned pb'd description of the "protocol"
> > and actually used the return to compose an invocation against the server.
> >  Nice.  Our 'protocols' actually already implement Service.Interface from
> > pb (actually Service.BlockingInterface).  I'm not sure why as it looks to
> > complicate things going by a quick examination today (I started stripping
> > it out to see what would break).  So it would not take too much to get a
> > Stub on clientside and have servers implement the Service.  We could try
> > shoehorning our RPC so it implemented the necessary RpcController, etc.
> > Interfaces.
> >
> > But it would seem Service is deprecated with a good while now [1] and
> > folks are encouraged to do otherwise because as is, the generated code
> > makes for too much "indirection" [1].
> >
> > I could try playing around some more w/ using Service to learn more about
> > this 'indirection'.  We could use the long-hand service descriptor in
> place
> > of the above suggested bitmap figuring what the server provides.
> >
> >
> I experimented hooking up protobuf Service to our RPC.  I put up a patch
> over on https://issues.apache.org/jira/browse/HBASE-6521 along w/ some
> notes made while messing.
> The main 'pro' is that our rpc would get a much needed spring cleaning.
>  Main 'con' is that we would be changing code (smile).  The main TODO is
> making sure no performance degradation (should be none server-side, need to
> make sure same is true client-side).
> This experiment has made me change my opinion regards 'versioning'.  Above
> I suggest we remove VersionedProtocol and add in instead a protobuf
> ProtocolDescriptor that would have a 'version' as well as a short and long
> form description of server 'features'.  Now I think we should just punt on
> version/descriptors altogether.  Lets just go the route where a method is
> supported or not.  That methods take a protobuf request and returns a
> protobuf response, as has been said already, gives us some wriggle room to
> evolve methods as time goes by.  For protocol migrations that require more
> this 'vocabulary', lets deal w/ them on a case by case basis (As per Enis
> above).
> St.Ack

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