FYI, I've also been looking into gRPC, as a tool to provide a (JGroups) version-independent service that all traffic is sent to and received from during a rolling cluster upgrade [1].
The focus of this is *version independence*, ie. have 3.6 and 4.x nodes talk to each other. A non-requirement is performance or memory consumption, as the service is only used during an upgrade (typically a couple of seconds). [1] https://github.com/jgroups-extras/RollingUpgrades/blob/master/common/src/main/proto/relay.proto On 28/05/18 16:47, Adrian Nistor wrote: > Hi Vittorio, > thanks for exploring gRPC. It seems like a very elegant solution for > exposing services. I'll have a look at your PoC soon. > > I feel there are some remarks that need to be made regarding gRPC. gRPC > is just some nice cheesy topping on top of protobuf. Google's > implementation of protobuf, to be more precise. > It does not need handwritten marshallers, but the 'No need for > marshaller' does not accurately describe it. Marshallers are needed and > are generated under the cover by the library and so are the data objects > and you are unfortunately forced to use them. That's both the good news > and the bad news:) The whole thing looks very promising and friendly for > many uses cases, especially for demos and PoCs :))). Nobody wants to > write those marshallers. But it starts to become a nuisance if you want > to use your own data objects. > There is also the ugliness and excessive memory footprint of the > generated code, which is the reason Infinispan did not adopt the > protobuf-java library although it did adopt protobuf as an encoding format. > The Protostream library was created as an alternative implementation to > solve the aforementioned problems with the generated code. It solves > this by letting the user provide their own data objects. And for the > marshallers it gives you two options: a) write the marshaller yourself > (hated), b) annotated your data objects and the marshaller gets > generated (loved). Protostream does not currently support service > definitions right now but this is something I started to investigate > recently after Galder asked me if I think it's doable. I think I'll only > find out after I do it:) > > Adrian > > On 05/28/2018 04:15 PM, Vittorio Rigamonti wrote: >> Hi Infinispan developers, >> >> I'm working on a solution for developers who need to access Infinispan >> services through different programming languages. >> >> The focus is not on developing a full featured client, but rather >> discover the value and the limits of this approach. >> >> - is it possible to automatically generate useful clients in different >> languages? >> - can that clients interoperate on the same cache with the same data >> types? >> >> I came out with a small prototype that I would like to submit to you >> and on which I would like to gather your impressions. >> >> You can found the project here [1]: is a gRPC-based client/server >> architecture for Infinispan based on and EmbeddedCache, with very few >> features exposed atm. >> >> Currently the project is nothing more than a poc with the following >> interesting features: >> >> - client can be generated in all the grpc supported language: java, >> go, c++ examples are provided; >> - the interface is full typed. No need for marshaller and clients >> build in different language can cooperate on the same cache; >> >> The second item is my preferred one beacuse it frees the developer >> from data marshalling. >> >> What do you think about? >> Sounds interesting? >> Can you see any flaw? >> >> There's also a list of issues for the future [2], basically I would >> like to investigate these questions: >> How far this architecture can go? >> Topology, events, queries... how many of the Infinispan features can >> be fit in a grpc architecture? >> >> Thank you >> Vittorio >> >> [1] https://github.com/rigazilla/ispn-grpc >> <https://github.com/rigazilla/ispn-grpc> >> [2] https://github.com/rigazilla/ispn-grpc/issues >> <https://github.com/rigazilla/ispn-grpc/issues> >> >> -- >> >> Vittorio Rigamonti >> >> Senior Software Engineer >> >> Red Hat >> >> <https://www.redhat.com> >> >> Milan, Italy >> >> vriga...@redhat.com <mailto:vriga...@redhat.com> >> >> irc: rigazilla >> >> <https://red.ht/sig> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Bela Ban | http://www.jgroups.org _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev