geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Baker <>
Subject Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol
Date Sat, 08 Apr 2017 00:22:50 GMT

> On Apr 7, 2017, at 3:11 PM, Galen M O'Sullivan <> wrote:
> I think the main selling point of an RPC framework/IDL is ease-of-use for
> defined remote communications that look like function calls. If you have
> calls you're making to remote servers asking them to do work, you can
> fairly trivially define the interface and then call through. You can then
> use native types in function calls and they transparently get transformed
> and sent across the wire.
> The RPC protocols I've seen are based on the idea that the types that can
> be sent will be predefined -- otherwise it's hard to describe with an IDL.
> However, we want to support storing unstructured data, or at least data
> structures that are defined (from the cluster's point of view) at runtime
> -- one of the main selling points of Geode is PDX serialization, which lets
> us store arbitrary object structures in the cache. If we were to use an RPC
> framework we have all the commands accept byte arrays and include some
> meta-information. This loses us the ease-of-use.

IMO, data encoding should be a separate concern from message definition.  I would advocate
that any approach we take should view the key/value fields as opaque bytes.  By keeping data
encoding and message definition separate, we can evolve them independently.

> What's left in the protocol then is the calls and the number of arguments
> they accept, and what order we put those (and the serialized arguments) in
> on the wire. I don't think we gain much by using a preexisting RPC
> language, and we lose control over the wire format and message structure.
> If we want to be able to make the protocol really fast, and customized to
> our use case; if we want to implement asynchronous requests, futures, etc.
> then we have to write wrappers for a given language anyways, and packing
> those things through an RPC framework like Thrift or gRPC will be an extra
> layer of confusing complexity.

I believe grpc supports an async API.  I would really love to see benchmark data for a get()
message using grpc.  Comparing that same message sent using an async netty implementation
would be instructive :-)

> Best,
> Galen


View raw message