6:47 a.m.
@Manik, great to hear from you! I also agree that gRPC brings a lot of
benefits to our client/server architecture. In fact, I'd personally be
happy to trade off "some" performance for all the benefits it brings.
@Adrian I think you hit the nail with this: "...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...". We didn't consider this
in 2010 when we first thought of using Google Protobuf to define Hot Rod
protocol:
http://lists.jboss.org/pipermail/infinispan-dev/2010-January/004936.html
That discussion ended with:
Manik and I were discussing this last week and came to the conclusion
that as suggested by David on his 1st paragraph, using it would be tying
us up to protobufs and its limitations, including the lack of support for
other languages such as C#.
That wasn't the only reason but it was one of the reasons. As Adrian
rightly points out, we could just have gone with it and then implement a
missing lang ourselves. That wasn't the only reason though, as I said in
the Javaland presentation on the topic, back in 2010, Google didn't have
much street credibility with open source libraries. No one knew what would
happen to Protobuf, whether it'd be open sourced and left to die... or
would evolve. Hindsight is a wonderful thing ;)
@Sanne, I've forgotten about that but yes! That's a very nice added feature
too. You can decide whether you have a sync or async client on the spot.
Both are generated. Also the "stream" keyboard for streaming multiple
elements is a nice feature for things like getAll
Cheers
Galder
On Wed, Jun 6, 2018 at 12:44 PM Sanne Grinovero <sanne(a)infinispan.org>
wrote:
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 <manik(a)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 <galder(a)redhat.com> wrote:
>>
>> On Wed, May 30, 2018 at 5:00 PM Radim Vansa <rvansa(a)redhat.com> wrote:
>>>
>>> On 05/30/2018 02:53 PM, Sanne Grinovero wrote:
>>> > On 30 May 2018 at 13:26, Adrian Nistor <anistor(a)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 <
anistor(a)redhat.com
>>> >>>>> <mailto:anistor@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
>>> >>>>>> <anistor(a)redhat.com
<mailto:anistor@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
>>> >>>>>>>
>>> >>>>>>> vrigamon(a)redhat.com
<mailto:vrigamon@redhat.com>
>>> >>>>>>>
>>> >>>>>>> irc: rigazilla
>>> >>>>>>>
>>> >>>>>>> <https://red.ht/sig>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
_______________________________________________
>>> >>>>>>> infinispan-dev mailing list
>>> >>>>>>> infinispan-dev(a)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
>>> >>>>>>
>>> >>>>>> vrigamon(a)redhat.com
<mailto:vrigamon@redhat.com>
>>> >>>>>>
>>> >>>>>> irc: rigazilla
>>> >>>>>>
>>> >>>>>> <https://red.ht/sig>
>>> >>>>> _______________________________________________
>>> >>>>> infinispan-dev mailing list
>>> >>>>> infinispan-dev(a)lists.jboss.org
>>> >>>>> <mailto:infinispan-dev@lists.jboss.org>
>>> >>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> infinispan-dev mailing list
>>> >>>>> infinispan-dev(a)lists.jboss.org
>>> >>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> infinispan-dev mailing list
>>> >>>> infinispan-dev(a)lists.jboss.org
>>> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >> _______________________________________________
>>> >> infinispan-dev mailing list
>>> >> infinispan-dev(a)lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> --
>>> Radim Vansa <rvansa(a)redhat.com>
>>> JBoss Performance Team
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev