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
