Re: Handling protocol versions

[Stack <st...@duboce.net>]

On Thu, Dec 27, 2012 at 7:11 PM, Stack <st...@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

Re: Handling protocol versions

[Stack <st...@duboce.net>]

On Wed, Jan 2, 2013 at 2:34 PM, Elliott Clark <ec...@apache.org> wrote:

> 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.
>
>
Let me try doing the above (Removing versioning and not going the pb
Service route).  We can't use BlockingInterface to replace
VersionedProtocol... BIs do not have a common ancestor.   Let me play
around....  I'll be back.


> 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.
>
>
I think this a good idea.  Will try this too.

Thanks E,
St.Ack

Re: Handling protocol versions

[Elliott Clark <ec...@apache.org>]

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 <st...@duboce.net> wrote:

> On Thu, Dec 27, 2012 at 7:11 PM, Stack <st...@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
>