Thanks Manik! Great to hear some feedback from you, especially as you have way more experience with gRPC.
Beyond helping to develop (and maintain!) clients for a wider range of programming languages - it would also help to provide both a "traditional" and a non-blocking client for each such language, while having to maintain just an async server implementation. Sanne On 6 June 2018 at 07:13, Manik Surtani <ma...@infinispan.org> wrote: > Hello everyone! (Wow, it's been a while since I dropped by and said hello... > ) > > Super-interesting discussion. > > Adrian: "What is the approach you envision regarding the IDL? Should we > strive for a pure IDL definition of the service? That could be an > interesting approach that would make it possible for a third party to > generate their own infinispan grpc client in any new language that we do not > already offer support, just based on the IDL. And maybe using a different > grpc implementation if they do not find suitable the one from google." > > This is spot-on, and where I see value in gRPC being incorporated into > Infinispan: making use of open(-ish) standards of RPC communication and > applying that to how we do client/server. Good discussion on handling > payload types in the interface definition. I've made use of some of the > ideas discussed here when creating a proto-defined IDL to look up ... more > serialized proto definitions for given types! Keen to see what your PoC > looks like. > > - M > > > On Wed, 30 May 2018 at 08:19 Galder Zamarreno <gal...@redhat.com> wrote: >> >> On Wed, May 30, 2018 at 5:00 PM Radim Vansa <rva...@redhat.com> wrote: >>> >>> On 05/30/2018 02:53 PM, Sanne Grinovero wrote: >>> > On 30 May 2018 at 13:26, Adrian Nistor <anis...@redhat.com> wrote: >>> >> Yest, the client needs that hash but that does not necessarily mean it >>> >> has to compute it itself. >>> >> The hash should be applied to the storage format which might be >>> >> different from the format the client sees. So hash computation could >>> >> be >>> >> done on the server, just a thought. >>> > Unless we want to explore some form of hybrid gRPC which benefits from >>> > Hot Rod intelligence level 3? >>> >>> Since Tristan said that gRPC is viable only if the performance is >>> comparable - I concluded that this involves the smart routing. I was >>> hoping that gRPC networking layer would provide some hook to specify the >>> destination. >> >> >> It does, via SubchannelPicker implementations. It requires key to be sent >> as HTTP header down the stack so that the SubchannelPicker can extract it. >> >> SubchannelPicker impl can then apply hash on it and decide based on >> available channels. >> >>> >>> An alternative would be a proxy hosted on the same node >>> that would do the routing. >>> >>> >>> If we're to replace Hot Rod I was expecting the (generated) gRPC client >>> to be extensible enough to allow us add client-side features (like near >>> cache, maybe listeners would need client-side code too) but saving us >>> most of the hassle with networking and parsing, while providing basic >>> client in languages we don't embrace without additional cost. >>> >>> R. >>> >>> > >>> > In which case the client will need to compute the hash before it can >>> > hint the network layer were to connect to. >>> > >>> > Thanks, >>> > Sanne >>> > >>> >> On 05/30/2018 02:47 PM, Radim Vansa wrote: >>> >>> On 05/30/2018 12:46 PM, Adrian Nistor wrote: >>> >>>> Thanks for clarifying this Galder. >>> >>>> Yes, the network layer is indeed the culprit and the purpose of this >>> >>>> experiment. >>> >>>> >>> >>>> What is the approach you envision regarding the IDL? Should we >>> >>>> strive >>> >>>> for a pure IDL definition of the service? That could be an >>> >>>> interesting >>> >>>> approach that would make it possible for a third party to generate >>> >>>> their own infinispan grpc client in any new language that we do not >>> >>>> already offer support, just based on the IDL. And maybe using a >>> >>>> different grpc implementation if they do not find suitable the one >>> >>>> from google. >>> >>>> >>> >>>> I was not suggesting we should do type transformation or anything on >>> >>>> the client side that would require an extra layer of code on top of >>> >>>> what grpc generates for the client, so maybe a pure IDL based >>> >>>> service >>> >>>> definition would indeed be possible, without extra helpers. No type >>> >>>> transformation, just type information. Exposing the type info that >>> >>>> comes from the server would be enough, a lot better than dumbing >>> >>>> everything down to a byte[]. >>> >>> I may be wrong but key transformation on client is necessary for >>> >>> correct >>> >>> hash-aware routing, isn't it? We need to get byte array for each key >>> >>> and >>> >>> apply murmur hash there (IIUC even when we use protobuf as the >>> >>> storage >>> >>> format, segment is based on the raw protobuf bytes, right?). >>> >>> >>> >>> Radim >>> >>> >>> >>>> Adrian >>> >>>> >>> >>>> On 05/30/2018 12:16 PM, Galder Zamarreno wrote: >>> >>>>> On Tue, May 29, 2018 at 8:57 PM Adrian Nistor <anis...@redhat.com >>> >>>>> <mailto:anis...@redhat.com>> wrote: >>> >>>>> >>> >>>>> Vittorio, a few remarks regarding your statement "...The >>> >>>>> alternative to this is to develop a protostream equivalent >>> >>>>> for >>> >>>>> each supported language and it doesn't seem really feasible >>> >>>>> to me." >>> >>>>> >>> >>>>> No way! That's a big misunderstanding. We do not need to >>> >>>>> re-implement the protostream library in C/C++/C# or any new >>> >>>>> supported language. >>> >>>>> Protostream is just for Java and it is compatible with >>> >>>>> Google's >>> >>>>> protobuf lib we already use in the other clients. We can >>> >>>>> continue >>> >>>>> using Google's protobuf lib for these clients, with or >>> >>>>> without gRPC. >>> >>>>> Protostream does not handle protobuf services as gRPC does, >>> >>>>> but >>> >>>>> we can add support for that with little effort. >>> >>>>> >>> >>>>> The real problem here is if we want to replace our hot rod >>> >>>>> invocation protocol with gRPC to save on the effort of >>> >>>>> implementing and maintaining hot rod in all those clients. I >>> >>>>> wonder why the obvious question is being avoided in this >>> >>>>> thread. >>> >>>>> >>> >>>>> >>> >>>>> ^ It is not being avoided. I stated it quite clearly when I replied >>> >>>>> but maybe not with enough detail. So, I said: >>> >>>>> >>> >>>>>> The biggest problem I see in our client/server architecture is >>> >>>>>> the >>> >>>>> ability to quickly deliver features/APIs across multiple language >>> >>>>> clients. Both Vittorio and I have seen how long it takes to >>> >>>>> implement >>> >>>>> all the different features available in Java client and port them >>> >>>>> to >>> >>>>> Node.js, C/C++/C#...etc. This effort lead by Vittorio is trying to >>> >>>>> improve on that by having some of that work done for us. Granted, >>> >>>>> not >>> >>>>> all of it will be done, but it should give us some good foundations >>> >>>>> on which to build. >>> >>>>> >>> >>>>> To expand on it a bit further: the reason it takes us longer to get >>> >>>>> different features in is because each client implements its own >>> >>>>> network layer, parses the protocol and does type transformations >>> >>>>> (between byte[] and whatever the client expects). >>> >>>>> >>> >>>>> IMO, the most costly things there are getting the network layer >>> >>>>> right >>> >>>>> (from experience with Node.js, it has taken a while to do so) and >>> >>>>> parsing work (not only parsing itself, but doing it in a efficient >>> >>>>> way). Network layer also includes load balancing, failover, cluster >>> >>>>> failover...etc. >>> >>>>> >>> >>>>> From past experience, transforming from byte[] to what the client >>> >>>>> expects has never really been very problematic for me. What's been >>> >>>>> difficult here is coming up with encoding architecture that Gustavo >>> >>>>> lead, whose aim was to improve on the initial compatibility mode. >>> >>>>> But, with that now clear, understood and proven to solve our >>> >>>>> issues, >>> >>>>> the rest in this area should be fairly straightforward IMO. >>> >>>>> >>> >>>>> Type transformation, once done, is a constant. As we add more Hot >>> >>>>> Rod >>> >>>>> operations, it's mostly the parsing that starts to become more >>> >>>>> work. >>> >>>>> Network can also become more work if instead of RPC commands you >>> >>>>> start supporting streams based commands. >>> >>>>> >>> >>>>> gRPC solves the network (FYI: with key as HTTP header and >>> >>>>> SubchannelPicker you can do hash-aware routing) and parsing for us. >>> >>>>> I >>> >>>>> don't see the need for it to solve our type transformations for us. >>> >>>>> If it does it, great, but does it support our compatibility >>> >>>>> requirements? (I had already told Vittorio to check Gustavo on >>> >>>>> this). >>> >>>>> Type transformation is a lower prio for me, network and parsing are >>> >>>>> more important. >>> >>>>> >>> >>>>> Hope this clarifies better my POV. >>> >>>>> >>> >>>>> Cheers >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Adrian >>> >>>>> >>> >>>>> >>> >>>>> On 05/29/2018 03:45 PM, Vittorio Rigamonti wrote: >>> >>>>>> Thanks Adrian, >>> >>>>>> >>> >>>>>> of course there's a marshalling work under the cover and >>> >>>>>> that is >>> >>>>>> reflected into the generated code (specially the accessor >>> >>>>>> methods generated from the oneof clause). >>> >>>>>> >>> >>>>>> My opinion is that on the client side this could be >>> >>>>>> accepted, as >>> >>>>>> long as the API are well defined and documented: application >>> >>>>>> developer can build an adhoc decorator on the top if needed. >>> >>>>>> The >>> >>>>>> alternative to this is to develop a protostream equivalent >>> >>>>>> for >>> >>>>>> each supported language and it doesn't seem really feasible >>> >>>>>> to me. >>> >>>>>> >>> >>>>>> On the server side (java only) the situation is different: >>> >>>>>> protobuf is optimized for streaming not for storing so >>> >>>>>> probably >>> >>>>>> a Protostream layer is needed. >>> >>>>>> >>> >>>>>> On Mon, May 28, 2018 at 4:47 PM, Adrian Nistor >>> >>>>>> <anis...@redhat.com <mailto:anis...@redhat.com>> 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 >>> >>>>>>> [2] 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 >>> >>>>>>> <mailto:infinispan-dev@lists.jboss.org> >>> >>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> -- >>> >>>>>> >>> >>>>>> 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 >>> >>>>> <mailto: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 >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> 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 >>> >>> >>> -- >>> Radim Vansa <rva...@redhat.com> >>> JBoss Performance Team >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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
