<div dir="ltr"><br><div class="gmail_extra">On Wed, May 30, 2018 at 10:56 AM, Adrian Nistor <span dir="ltr"><<a href="mailto:anistor@redhat.com" target="_blank">anistor@redhat.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_-1046137647920781934moz-cite-prefix">The oneof and WrappedMessage solve the
same problem but in a different way.<br>
Oneof has the nasty effect that in ties the service model to the
user data model. </div></div></blockquote><div><br></div><div><br></div><div>The user data model is only "static" at storage level (guided by configuration), and the user data can travel on the wire in any format the user wants [1]<br></div><div><br></div><div>[1] <a href="https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/test/java/org/infinispan/client/hotrod/transcoding/DataFormatTest.java#L109">https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/test/java/org/infinispan/client/hotrod/transcoding/DataFormatTest.java#L109</a><br></div><div><br></div><div>So better not to assume it will be marshalled and unmarshalled in a specific way.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div class="gmail-m_-1046137647920781934moz-cite-prefix">Even if it seems like just one more line of code
to add when a new user type is introduced, it is one line of code
in the wrong place because you'll have to re-generate the service.
IE user run protoc again on OUR IDLs. Should a user do that? This
coupling between the infinispan's service model and the user's
data model bothers me. <br>
<br>
WrappedMessage is just a wrapper around an array of bytes +
information regarding what message type or what scalar type is in
there. Something very similar to a VARIANT [1]. The reason it is
needed is explained here [2].<br>
<br>
You are correct, this is not a gRPC limitation, it is a by-design
protobuf protocol limitation, that was very thoughtfully
introduced to reduce wire level bandwitdth for the common case
where types are static. Unfortunately it leaves generic/dynamic
types in mid-air. But it is fairly easy to solve, as you can see
with WrappedMessage. At the time I introduced WrappedMessage we
were using protobuf 2.<br>
<br>
protobuf 3 introduces type Any, which solves the issue in a
similar way with WrappedMessage. The difference is Any seems to
have been created to wrap either a plain byte[] or a message type
that has been marshalled to a byte[]. No support for scalars in
sight. Can we solve that? Sure, put a WrappedMessage inside that
byte[] :)))) That is the reason I did not jump immediately at
using Any and stayed with WrappedMessage.<br>
<br>
Can a 150 lines PoC be a proposal for the ISPN object model? No,
but we need to explore the pain points of gRPC and protobuf that
are relevant to our usage, and this thing with genericly typed
services is one of them.<br>
I think we already have a good solution in sight, before giving up
and going with byte[] for key and value as it was suggested
earlier here. I can make a PR to the grpc PoC to show it by the
end of the week.<br>
<br>
Adrian<br>
<br>
[1] <a class="gmail-m_-1046137647920781934moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Variant_type" target="_blank">https://en.wikipedia.org/wiki/<wbr>Variant_type</a><br>
[2]
<a class="gmail-m_-1046137647920781934moz-txt-link-freetext" href="https://developers.google.com/protocol-buffers/docs/techniques#streaming" target="_blank">https://developers.google.com/<wbr>protocol-buffers/docs/<wbr>techniques#streaming</a><div><div class="gmail-h5"><br>
<br>
On 05/30/2018 11:34 AM, Vittorio Rigamonti wrote:<br>
</div></div></div><div><div class="gmail-h5">
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, May 29, 2018 at 8:59 PM,
Adrian Nistor <span dir="ltr"><<a href="mailto:anistor@redhat.com" target="_blank">anistor@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_-1046137647920781934m_-7719467217180458836moz-cite-prefix">So
you assume the two are separate, Emmanuel. So do I.<br>
<br>
But in the current PoC the user data model is directly
referenced by the service model interface (KeyMsg and
ValueMsg are oneofs listing all possible user
application types???). I was assuming this hard
dependency was there just to make things simple for
the scope of the PoC. But let's not make this too
simple because it will stop being useful. My
expectation is to see a generic yet fully typed 'cache
service' interface that does not depend on the key and
value types that come from userland, using maybe
'google.protobuf.Any' or our own 'WrappedMessage' type
instead. I'm not sure what to believe now because
discussing my hopes and assumptions on the gRPC topic
on zulip I think I understood the opposite is
desired. Vittorio, please comment on this.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yep that was my design choice. Well my first goal was
to keep the framework language independent: to reach that
I tried to define in grpc/protobuf as much as possible
(that's why I didn't use the Any clause). Then I realized
that with very little effort I could design a framework
that works only with user data from the user side to the
cache storage and I'd liked to investigate this, manly
for two reasons:<br>
<br>
</div>
<div>- from the user point of view I like the idea that I
can found my objects types in the cache<br>
</div>
<div>- the embeddedCache<object,object> is
transparently exposed<br>
<br>
</div>
<div>but this is my 150 lines of code grpc server prototype,
not a proposal for the ISPN object model. However it's ok
to use it as starting point for a wider discussion<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_-1046137647920781934m_-7719467217180458836moz-cite-prefix"> <br>
I'm still hoping we want to keep the service interface
generic and separated from the user model. And if we
do it, would you expect to be able to marshall the
service call using gRPC lib and at the same time be
able to marshall the user model using whatever other
library? Would be nice but that seems to be a no-no
with gRPC, or I did not search deep enough. I only
looked at the java implementation anyway. It seems to
be forcing you to go with protoc generated code and
protobuf-java.jar all the way, for marshalling both
the service and its arguments. And this goes
infinitely deeper. If a service argument of type A has
a nested field of type B and the marshaller for A is
generated with protobuf-java then so is B. Using
oneofs or type 'Any' still do not save you from this.
The only escape is to pretend the user payload is of
type 'bytes'. At that point you are left to do your
marshaling to and from bytes yourself. And you are
also left with the question, what the heck is the
contents of that byte array next time you unmarshall
it, which is currently answered by WrappedMessage.<br>
</div>
</div>
</blockquote>
<div> </div>
<div>And indeed the "oneof" clause in my message definition
solves the same problem solved by the WrappedMessage
message: what I have to do with these bytes? Actually I'm
not sure this is a gRPC limitation: if I receive a stream
of bytes I also need some info on what I have to
reconstruct.... I'm just guessing<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_-1046137647920781934m_-7719467217180458836moz-cite-prefix"> <br>
So the more I look at gRPC it seems elegant for most
purposes but lacking for ours. And again, as with
protocol buffers, the wire protocol and the IDL are
really nice. It is the implementation that is lacking,
IMHO.<br>
<br>
I think to be really on the same page we should first
make a clear statement of what we intend to achieve
here in a bit more detail. Also, since this is not a
clean slate effort, we should think right from the
start what are the expected interactions with existing
code base, like what are we willing to sacrifice.
Somebody mention hot rod please!<span class="gmail-m_-1046137647920781934HOEnZb"><font color="#888888"><br>
<br>
Adrian</font></span>
<div>
<div class="gmail-m_-1046137647920781934h5"><br>
<br>
<br>
On 05/29/2018 07:20 PM, Emmanuel Bernard wrote:<br>
</div>
</div>
</div>
<div>
<div class="gmail-m_-1046137647920781934h5">
<blockquote type="cite">
<div>Right. Here we are talking about a gRPC
representation of the client server
interactions. Not the data schema stored in
ISPN. In that model, the API is compiled by us
and handed over as a package. </div>
<div><br>
On 29 May 2018, at 15:51, Sanne Grinovero <<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div style="font-size:small"><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 29 May 2018 at
13:45, Vittorio Rigamonti <span dir="ltr"><<a href="mailto:vrigamon@redhat.com" target="_blank">vrigamon@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>
<div>Thanks Adrian,<br>
<br>
</div>
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).<br>
<br>
</div>
<div>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.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<div style="font-size:small">This
might indeed be reasonable for some
developers, some languages.</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">Just
please make sure it's not the only
option, as many other developers
will not expect to need a compiler
at hand in various stages of the
application lifecycle.</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">For
example when deploying a JPA model
into an appserver, or just booting
Hibernate in JavaSE as well, there
is a strong expectation that we'll
be able - at runtime - to inspect
the listed Java POJOs via reflection
and automatically generate whatever
Infinispan will need.</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">Perhaps a
key differentiator is between
invoking Infinispan APIs (RPC) vs
defining the object models and
related CODECs for keys, values,
streams and query results? It might
get a bit more fuzzy to
differentiate them for custom
functions but I guess we can draw a
line somewhere.</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">Thanks,</div>
<div style="font-size:small">Sanne</div>
<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>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.<br>
</div>
</div>
<div class="gmail-m_-1046137647920781934m_-7719467217180458836HOEnZb">
<div class="gmail-m_-1046137647920781934m_-7719467217180458836h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon,
May 28, 2018 at 4:47 PM,
Adrian Nistor <span dir="ltr"><<a href="mailto:anistor@redhat.com" target="_blank">anistor@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651m_4400301142433856756moz-cite-prefix">Hi
Vittorio,<br>
thanks for exploring
gRPC. It seems like a
very elegant solution
for exposing services.
I'll have a look at your
PoC soon.<br>
<br>
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. <br>
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.<br>
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.<br>
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:)<br>
<br>
Adrian
<div>
<div class="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651h5"><br>
<br>
On 05/28/2018 04:15
PM, Vittorio
Rigamonti wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651h5">
<div dir="ltr">
<div>Hi Infinispan
developers,<br>
<br>
</div>
<div>I'm working
on a solution
for developers
who need to
access
Infinispan
services
through
different
programming
languages.<br>
</div>
<div><br>
The focus is not
on developing a
full featured
client, but
rather discover
the value and
the limits of
this approach.<br>
<div><br>
</div>
</div>
<div>- is it
possible to
automatically
generate useful
clients in
different
languages?<br>
</div>
<div>- can that
clients
interoperate on
the same cache
with the same
data types?<br>
</div>
<div><br>
</div>
<span id="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651m_4400301142433856756m_-8148977098275501500gmail-result_box" class="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651m_4400301142433856756m_-8148977098275501500gmail-" lang="en"><span class="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651m_4400301142433856756m_-8148977098275501500gmail-">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.</span></span><br>
<div><br>
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.<br>
</div>
<div><br>
Currently the
project is
nothing more
than a poc with
the following
interesting
features:<br>
<br>
</div>
<div>- client can
be generated in
all the grpc
supported
language: java,
go, c++ examples
are provided;<br>
</div>
<div>- the
interface is
full typed. No
need for
marshaller and
clients build in
different
language can
cooperate on the
same cache;<br>
</div>
<div><br>
</div>
<div>The second
item is my
preferred one
beacuse it frees
the developer
from data
marshalling.<br>
<br>
</div>
<div>What do you
think about?<br>
</div>
<div>Sounds
interesting?<br>
</div>
<div>Can you see
any flaw?<br>
</div>
<div><br>
There's also a
list of issues
for the future
[2], basically I
would like to
investigate
these questions:<br>
How far this
architecture can
go?<br>
Topology,
events,
queries... how
many of the
Infinispan
features can be
fit in a grpc
architecture?<br>
</div>
<div><br>
</div>
<div>Thank you<br>
</div>
<div>Vittorio<br>
</div>
<br>
[1] <a href="https://github.com/rigazilla/ispn-grpc" target="_blank">https://github.com/rigazilla/i<wbr>spn-grpc</a><br clear="all">
<div>
<div>
<div>[2] <a href="https://github.com/rigazilla/ispn-grpc/issues" target="_blank">https://github.com/rigazilla/i<wbr>spn-grpc/issues</a><br clear="all">
<br>
</div>
<div>-- <br>
<div class="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651m_4400301142433856756m_-8148977098275501500gmail-m_-8431198291286624134m_1982721755148179188gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<p style="font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span>Vittorio</span>
<span>Rigamonti</span></p>
<p style="font-weight:normal;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>Senior
Software
Engineer</span></p>
<p style="font-weight:normal;margin:0px;font-size:10px;color:rgb(153,153,153)"><a style="color:rgb(0,136,206);font-size:10px;margin:0px;text-decoration:none;font-family:"overpass",sans-serif" href="https://www.redhat.com" target="_blank">Red
Hat <span><br>
<br>
</span></a></p>
<span style="font-size:10px;margin:0px;color:rgb(153,153,153)">
<p style="font-size:10px;margin:0px">Milan,
Italy</p>
</span>
<p style="font-weight:normal;margin:0px 0px 6px;font-size:10px;color:rgb(153,153,153)"><span style="margin:0px;padding:0px"> <a style="color:rgb(0,136,206);font-size:10px;margin:0px;text-decoration:none;font-family:"overpass",sans-serif" href="mailto:vrigamon@redhat.com" target="_blank">vrigamon@redhat.com</a><br>
</span></p>
<p style="font-weight:normal;margin:0px 0px 6px;font-size:10px;color:rgb(153,153,153)"><span style="margin:0px;padding:0px">irc: rigazilla </span> </p>
<a href="https://red.ht/sig" target="_blank"> <img src="https://www.redhat.com/profiles/rh/themes/redhatdotcom/img/logo-red-hat-black.png" height="auto" width="90"></a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651m_4400301142433856756mimeAttachmentHeader"></fieldset>
<br>
</div>
</div>
<pre>______________________________<wbr>_________________
infinispan-dev mailing list
<a class="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651m_4400301142433856756moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>
<a class="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651m_4400301142433856756moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a></pre>
</blockquote>
<p><br>
</p>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div class="gmail-m_-1046137647920781934m_-7719467217180458836m_4216121092935601651gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<p style="font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span>Vittorio</span>
<span>Rigamonti</span></p>
<p style="font-weight:normal;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>Senior
Software Engineer</span></p>
<p style="font-weight:normal;margin:0px;font-size:10px;color:rgb(153,153,153)"><a style="color:rgb(0,136,206);font-size:10px;margin:0px;text-decoration:none;font-family:"overpass",sans-serif" href="https://www.redhat.com" target="_blank">Red
Hat <span><br>
<br>
</span></a></p>
<span style="font-size:10px;margin:0px;color:rgb(153,153,153)">
<p style="font-size:10px;margin:0px">Milan,
Italy</p>
</span>
<p style="font-weight:normal;margin:0px 0px 6px;font-size:10px;color:rgb(153,153,153)"><span style="margin:0px;padding:0px"> <a style="color:rgb(0,136,206);font-size:10px;margin:0px;text-decoration:none;font-family:"overpass",sans-serif" href="mailto:vrigamon@redhat.com" target="_blank">vrigamon@redhat.com</a><br>
</span></p>
<p style="font-weight:normal;margin:0px 0px 6px;font-size:10px;color:rgb(153,153,153)"><span style="margin:0px;padding:0px">irc: rigazilla </span> </p>
<a href="https://red.ht/sig" target="_blank">
<img src="https://www.redhat.com/profiles/rh/themes/redhatdotcom/img/logo-red-hat-black.png" height="auto" width="90"></a></div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>______________________________<wbr>_________________</span><br>
<span>infinispan-dev mailing list</span><br>
<span><a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a></span><br>
<span><a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a></span></div>
</blockquote>
<br>
<fieldset class="gmail-m_-1046137647920781934m_-7719467217180458836mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
infinispan-dev mailing list
<a class="gmail-m_-1046137647920781934m_-7719467217180458836moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>
<a class="gmail-m_-1046137647920781934m_-7719467217180458836moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a></pre>
</blockquote>
<p><br>
</p>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div class="gmail-m_-1046137647920781934gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<p style="font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span>Vittorio</span>
<span>Rigamonti</span></p>
<p style="font-weight:normal;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>Senior
Software Engineer</span></p>
<p style="font-weight:normal;margin:0px;font-size:10px;color:rgb(153,153,153)"><a style="color:rgb(0,136,206);font-size:10px;margin:0px;text-decoration:none;font-family:"overpass",sans-serif" href="https://www.redhat.com" target="_blank">Red Hat <span><br>
<br>
</span></a></p>
<span style="font-size:10px;margin:0px;color:rgb(153,153,153)">
<p style="font-size:10px;margin:0px">Milan, Italy</p>
</span>
<p style="font-weight:normal;margin:0px 0px 6px;font-size:10px;color:rgb(153,153,153)"><span style="margin:0px;padding:0px">
<a style="color:rgb(0,136,206);font-size:10px;margin:0px;text-decoration:none;font-family:"overpass",sans-serif" href="mailto:vrigamon@redhat.com" target="_blank">vrigamon@redhat.com</a><br>
</span></p>
<p style="font-weight:normal;margin:0px 0px 6px;font-size:10px;color:rgb(153,153,153)"><span style="margin:0px;padding:0px">irc: rigazilla </span>
</p>
<a href="https://red.ht/sig" target="_blank"> <img src="https://www.redhat.com/profiles/rh/themes/redhatdotcom/img/logo-red-hat-black.png" height="auto" width="90"></a></div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
</div></div></div>
<br>______________________________<wbr>_________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a><br></blockquote></div><br></div></div>