[infinispan-dev] Single Endpoint design

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] Single Endpoint design

Sebastian Laskawiec
Hey!

My plan is to start working on a Single Point support for Infinispan Server very soon and I prepared a design: https://github.com/infinispan/infinispan/pull/5041

As you can see I did not use our Wiki (as we used to) because it doesn't support inline comments (which is pretty bad in my opinion). I would like to propose to keep all the designs along with our source code. This approach has been successfully used by the Kubernetes [1] folks (although they migrated designs into the new Community repository [2] recently). I think it might be a good idea to do something similar.

Feedback on both items is more than welcome.

Thanks,
Sebastian


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Single Endpoint design

Gustavo Fernandes-2
Hi Sebastian,

If I understood it correctly, all the Hot Rod clients will be changed from using:

- Binary over TCP, circa 40 bytes header, no hops to contact the server, no protocol negotiation, no encryption (default)

to

- HTTP/2 with SSL, protocol upgrade negotiation, and a hop (router) to connect to the server.


Any idea of how significant would be this extra overhead introduced?


Thanks,
Gustavo


On Thu, Mar 30, 2017 at 2:01 PM, Sebastian Laskawiec <[hidden email]> wrote:
Hey!

My plan is to start working on a Single Point support for Infinispan Server very soon and I prepared a design: https://github.com/infinispan/infinispan/pull/5041

As you can see I did not use our Wiki (as we used to) because it doesn't support inline comments (which is pretty bad in my opinion). I would like to propose to keep all the designs along with our source code. This approach has been successfully used by the Kubernetes [1] folks (although they migrated designs into the new Community repository [2] recently). I think it might be a good idea to do something similar.

Feedback on both items is more than welcome.

Thanks,
Sebastian


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Single Endpoint design

Tristan Tarrant-2
You understood incorrectly.
The only change to the Hot Rod clients is that, if they get a 400 error
from a HR PING request, they will initiate an upgrade to Hot Rod and
then proceed with the usual Hot Rod protocol after that.

Tristan

On 31/03/2017 11:58, Gustavo Fernandes wrote:

> Hi Sebastian,
>
> If I understood it correctly, all the Hot Rod clients will be changed
> from using:
>
> - Binary over TCP, circa 40 bytes header, no hops to contact the server,
> no protocol negotiation, no encryption (default)
>
> to
>
> - HTTP/2 with SSL, protocol upgrade negotiation, and a hop (router) to
> connect to the server.
>
>
> Any idea of how significant would be this extra overhead introduced?
>
>
> Thanks,
> Gustavo
>
>
> On Thu, Mar 30, 2017 at 2:01 PM, Sebastian Laskawiec
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hey!
>
>     My plan is to start working on a Single Point support for Infinispan
>     Server very soon and I prepared a design:
>     https://github.com/infinispan/infinispan/pull/5041
>     <https://github.com/infinispan/infinispan/pull/5041>
>
>     As you can see I did not use our Wiki (as we used to) because it
>     doesn't support inline comments (which is pretty bad in my opinion).
>     I would like to propose to keep all the designs along with our
>     source code. This approach has been successfully used by the
>     Kubernetes [1] folks (although they migrated designs into the new
>     Community repository [2] recently). I think it might be a good idea
>     to do something similar.
>
>     Feedback on both items is more than welcome.
>
>     Thanks,
>     Sebastian
>
>     [1]
>     https://github.com/kubernetes/kubernetes/tree/master/docs/proposals
>     <https://github.com/kubernetes/kubernetes/tree/master/docs/proposals>
>     [2]
>     https://github.com/kubernetes/community/tree/master/contributors/design-proposals
>     <https://github.com/kubernetes/community/tree/master/contributors/design-proposals>
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Single Endpoint design

Gustavo Fernandes-2
On Fri, Mar 31, 2017 at 11:02 AM, Tristan Tarrant <[hidden email]> wrote:
You understood incorrectly.
The only change to the Hot Rod clients is that, if they get a 400 error
from a HR PING request, they will initiate an upgrade to Hot Rod and
then proceed with the usual Hot Rod protocol after that.


Thanks for the clarification. Still, after the HR protocol is negotiated, communication will go
through a router, thus adding an extra hop?

Gustavo

Tristan

On 31/03/2017 11:58, Gustavo Fernandes wrote:
> Hi Sebastian,
>
> If I understood it correctly, all the Hot Rod clients will be changed
> from using:
>
> - Binary over TCP, circa 40 bytes header, no hops to contact the server,
> no protocol negotiation, no encryption (default)
>
> to
>
> - HTTP/2 with SSL, protocol upgrade negotiation, and a hop (router) to
> connect to the server.
>
>
> Any idea of how significant would be this extra overhead introduced?
>
>
> Thanks,
> Gustavo
>
>
> On Thu, Mar 30, 2017 at 2:01 PM, Sebastian Laskawiec
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hey!
>
>     My plan is to start working on a Single Point support for Infinispan
>     Server very soon and I prepared a design:
>     https://github.com/infinispan/infinispan/pull/5041
>     <https://github.com/infinispan/infinispan/pull/5041>
>
>     As you can see I did not use our Wiki (as we used to) because it
>     doesn't support inline comments (which is pretty bad in my opinion).
>     I would like to propose to keep all the designs along with our
>     source code. This approach has been successfully used by the
>     Kubernetes [1] folks (although they migrated designs into the new
>     Community repository [2] recently). I think it might be a good idea
>     to do something similar.
>
>     Feedback on both items is more than welcome.
>
>     Thanks,
>     Sebastian
>
>     [1]
>     https://github.com/kubernetes/kubernetes/tree/master/docs/proposals
>     <https://github.com/kubernetes/kubernetes/tree/master/docs/proposals>
>     [2]
>     https://github.com/kubernetes/community/tree/master/contributors/design-proposals
>     <https://github.com/kubernetes/community/tree/master/contributors/design-proposals>
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Single Endpoint design

Tristan Tarrant-2
No, once the connection is established, I believe the netty pipeline can
be trimmed to the necessary elements.

Tristan

On 31/03/2017 13:57, Gustavo Fernandes wrote:

> On Fri, Mar 31, 2017 at 11:02 AM, Tristan Tarrant <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     You understood incorrectly.
>     The only change to the Hot Rod clients is that, if they get a 400 error
>     from a HR PING request, they will initiate an upgrade to Hot Rod and
>     then proceed with the usual Hot Rod protocol after that.
>
>
> Thanks for the clarification. Still, after the HR protocol is
> negotiated, communication will go
> through a router, thus adding an extra hop?
>
> Gustavo
>
>     Tristan
>
>     On 31/03/2017 11:58, Gustavo Fernandes wrote:
>     > Hi Sebastian,
>     >
>     > If I understood it correctly, all the Hot Rod clients will be changed
>     > from using:
>     >
>     > - Binary over TCP, circa 40 bytes header, no hops to contact the server,
>     > no protocol negotiation, no encryption (default)
>     >
>     > to
>     >
>     > - HTTP/2 with SSL, protocol upgrade negotiation, and a hop (router) to
>     > connect to the server.
>     >
>     >
>     > Any idea of how significant would be this extra overhead introduced?
>     >
>     >
>     > Thanks,
>     > Gustavo
>     >
>     >
>     > On Thu, Mar 30, 2017 at 2:01 PM, Sebastian Laskawiec
>      > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >
>      >     Hey!
>      >
>      >     My plan is to start working on a Single Point support for
>     Infinispan
>      >     Server very soon and I prepared a design:
>      > https://github.com/infinispan/infinispan/pull/5041
>     <https://github.com/infinispan/infinispan/pull/5041>
>      >     <https://github.com/infinispan/infinispan/pull/5041
>     <https://github.com/infinispan/infinispan/pull/5041>>
>      >
>      >     As you can see I did not use our Wiki (as we used to) because it
>      >     doesn't support inline comments (which is pretty bad in my
>     opinion).
>      >     I would like to propose to keep all the designs along with our
>      >     source code. This approach has been successfully used by the
>      >     Kubernetes [1] folks (although they migrated designs into the new
>      >     Community repository [2] recently). I think it might be a
>     good idea
>      >     to do something similar.
>      >
>      >     Feedback on both items is more than welcome.
>      >
>      >     Thanks,
>      >     Sebastian
>      >
>      >     [1]
>      >
>     https://github.com/kubernetes/kubernetes/tree/master/docs/proposals
>     <https://github.com/kubernetes/kubernetes/tree/master/docs/proposals>
>      >  
>       <https://github.com/kubernetes/kubernetes/tree/master/docs/proposals <https://github.com/kubernetes/kubernetes/tree/master/docs/proposals>>
>      >     [2]
>      >
>     https://github.com/kubernetes/community/tree/master/contributors/design-proposals
>     <https://github.com/kubernetes/community/tree/master/contributors/design-proposals>
>      >  
>       <https://github.com/kubernetes/community/tree/master/contributors/design-proposals <https://github.com/kubernetes/community/tree/master/contributors/design-proposals>>
>      >
>      >     _______________________________________________
>      >     infinispan-dev mailing list
>      > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>      >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>>
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>     >
>
>     --
>     Tristan Tarrant
>     Infinispan Lead
>     JBoss, a division of Red Hat
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Single Endpoint design

Sebastian Laskawiec
With TLS+ALPN the use case is very simple. The protocol is negotiated during the handshake. Then the existing TCP connection is reused and the client starts to send Hot Rod binary bits through the wire. Sadly, TLS adds some significant overhead to the transmission.

With HTTP/1.1 Upgrade it's a bit more complicated. The Upgrade request might issued by the client as well as by the server. Each of the parties can ignore the request if it doesn't recognize it (or doesn't support protocols proposed by the other side). The more I think about this, the more I lean towards to server initiated upgrade requests. This way, only clients which supports the upgrade will react to it. It still needs some more thought...

Of course you are right, some additional code will need to be added to the clients to support switching protocols. The good news is that you won't be forced to use the Single Endpoint. You may want to expose our old, good Hot Rod Endpoint and forget about all this switching complexity.

Regarding to network hops - no, there is no additional network hops. The router component simply identifies the incoming request and plugs proper Netty Handler stack to it. Here's an example how it is done with multi-tenancy based on SNI [1]. 


On Fri, Mar 31, 2017 at 2:22 PM Tristan Tarrant <[hidden email]> wrote:
No, once the connection is established, I believe the netty pipeline can
be trimmed to the necessary elements.

Tristan

On 31/03/2017 13:57, Gustavo Fernandes wrote:
> On Fri, Mar 31, 2017 at 11:02 AM, Tristan Tarrant <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     You understood incorrectly.
>     The only change to the Hot Rod clients is that, if they get a 400 error
>     from a HR PING request, they will initiate an upgrade to Hot Rod and
>     then proceed with the usual Hot Rod protocol after that.
>
>
> Thanks for the clarification. Still, after the HR protocol is
> negotiated, communication will go
> through a router, thus adding an extra hop?
>
> Gustavo
>
>     Tristan
>
>     On 31/03/2017 11:58, Gustavo Fernandes wrote:
>     > Hi Sebastian,
>     >
>     > If I understood it correctly, all the Hot Rod clients will be changed
>     > from using:
>     >
>     > - Binary over TCP, circa 40 bytes header, no hops to contact the server,
>     > no protocol negotiation, no encryption (default)
>     >
>     > to
>     >
>     > - HTTP/2 with SSL, protocol upgrade negotiation, and a hop (router) to
>     > connect to the server.
>     >
>     >
>     > Any idea of how significant would be this extra overhead introduced?
>     >
>     >
>     > Thanks,
>     > Gustavo
>     >
>     >
>     > On Thu, Mar 30, 2017 at 2:01 PM, Sebastian Laskawiec
>      > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >
>      >     Hey!
>      >
>      >     My plan is to start working on a Single Point support for
>     Infinispan
>      >     Server very soon and I prepared a design:
>      > https://github.com/infinispan/infinispan/pull/5041
>     <https://github.com/infinispan/infinispan/pull/5041>
>      >     <https://github.com/infinispan/infinispan/pull/5041
>     <https://github.com/infinispan/infinispan/pull/5041>>
>      >
>      >     As you can see I did not use our Wiki (as we used to) because it
>      >     doesn't support inline comments (which is pretty bad in my
>     opinion).
>      >     I would like to propose to keep all the designs along with our
>      >     source code. This approach has been successfully used by the
>      >     Kubernetes [1] folks (although they migrated designs into the new
>      >     Community repository [2] recently). I think it might be a
>     good idea
>      >     to do something similar.
>      >
>      >     Feedback on both items is more than welcome.
>      >
>      >     Thanks,
>      >     Sebastian
>      >
>      >     [1]
>      >
>     https://github.com/kubernetes/kubernetes/tree/master/docs/proposals
>     <https://github.com/kubernetes/kubernetes/tree/master/docs/proposals>
>      >
>       <https://github.com/kubernetes/kubernetes/tree/master/docs/proposals <https://github.com/kubernetes/kubernetes/tree/master/docs/proposals>>
>      >     [2]
>      >
>     https://github.com/kubernetes/community/tree/master/contributors/design-proposals
>     <https://github.com/kubernetes/community/tree/master/contributors/design-proposals>
>      >
>       <https://github.com/kubernetes/community/tree/master/contributors/design-proposals <https://github.com/kubernetes/community/tree/master/contributors/design-proposals>>
>      >
>      >     _______________________________________________
>      >     infinispan-dev mailing list
>      > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>      >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>>
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>     >
>
>     --
>     Tristan Tarrant
>     Infinispan Lead
>     JBoss, a division of Red Hat
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Single Endpoint design

Sebastian Laskawiec
The design has been moved here: https://github.com/infinispan/infinispan-designs/pull/2

Are there any last comments? I plan to start working on that shortly.

Thanks,
Sebastian

On Fri, Mar 31, 2017 at 4:20 PM Sebastian Laskawiec <[hidden email]> wrote:
With TLS+ALPN the use case is very simple. The protocol is negotiated during the handshake. Then the existing TCP connection is reused and the client starts to send Hot Rod binary bits through the wire. Sadly, TLS adds some significant overhead to the transmission.

With HTTP/1.1 Upgrade it's a bit more complicated. The Upgrade request might issued by the client as well as by the server. Each of the parties can ignore the request if it doesn't recognize it (or doesn't support protocols proposed by the other side). The more I think about this, the more I lean towards to server initiated upgrade requests. This way, only clients which supports the upgrade will react to it. It still needs some more thought...

Of course you are right, some additional code will need to be added to the clients to support switching protocols. The good news is that you won't be forced to use the Single Endpoint. You may want to expose our old, good Hot Rod Endpoint and forget about all this switching complexity.

Regarding to network hops - no, there is no additional network hops. The router component simply identifies the incoming request and plugs proper Netty Handler stack to it. Here's an example how it is done with multi-tenancy based on SNI [1]. 


On Fri, Mar 31, 2017 at 2:22 PM Tristan Tarrant <[hidden email]> wrote:
No, once the connection is established, I believe the netty pipeline can
be trimmed to the necessary elements.

Tristan

On 31/03/2017 13:57, Gustavo Fernandes wrote:
> On Fri, Mar 31, 2017 at 11:02 AM, Tristan Tarrant <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     You understood incorrectly.
>     The only change to the Hot Rod clients is that, if they get a 400 error
>     from a HR PING request, they will initiate an upgrade to Hot Rod and
>     then proceed with the usual Hot Rod protocol after that.
>
>
> Thanks for the clarification. Still, after the HR protocol is
> negotiated, communication will go
> through a router, thus adding an extra hop?
>
> Gustavo
>
>     Tristan
>
>     On 31/03/2017 11:58, Gustavo Fernandes wrote:
>     > Hi Sebastian,
>     >
>     > If I understood it correctly, all the Hot Rod clients will be changed
>     > from using:
>     >
>     > - Binary over TCP, circa 40 bytes header, no hops to contact the server,
>     > no protocol negotiation, no encryption (default)
>     >
>     > to
>     >
>     > - HTTP/2 with SSL, protocol upgrade negotiation, and a hop (router) to
>     > connect to the server.
>     >
>     >
>     > Any idea of how significant would be this extra overhead introduced?
>     >
>     >
>     > Thanks,
>     > Gustavo
>     >
>     >
>     > On Thu, Mar 30, 2017 at 2:01 PM, Sebastian Laskawiec
>      > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >
>      >     Hey!
>      >
>      >     My plan is to start working on a Single Point support for
>     Infinispan
>      >     Server very soon and I prepared a design:
>      > https://github.com/infinispan/infinispan/pull/5041
>     <https://github.com/infinispan/infinispan/pull/5041>
>      >     <https://github.com/infinispan/infinispan/pull/5041
>     <https://github.com/infinispan/infinispan/pull/5041>>
>      >
>      >     As you can see I did not use our Wiki (as we used to) because it
>      >     doesn't support inline comments (which is pretty bad in my
>     opinion).
>      >     I would like to propose to keep all the designs along with our
>      >     source code. This approach has been successfully used by the
>      >     Kubernetes [1] folks (although they migrated designs into the new
>      >     Community repository [2] recently). I think it might be a
>     good idea
>      >     to do something similar.
>      >
>      >     Feedback on both items is more than welcome.
>      >
>      >     Thanks,
>      >     Sebastian
>      >
>      >     [1]
>      >
>     https://github.com/kubernetes/kubernetes/tree/master/docs/proposals
>     <https://github.com/kubernetes/kubernetes/tree/master/docs/proposals>
>      >
>       <https://github.com/kubernetes/kubernetes/tree/master/docs/proposals <https://github.com/kubernetes/kubernetes/tree/master/docs/proposals>>
>      >     [2]
>      >
>     https://github.com/kubernetes/community/tree/master/contributors/design-proposals
>     <https://github.com/kubernetes/community/tree/master/contributors/design-proposals>
>      >
>       <https://github.com/kubernetes/community/tree/master/contributors/design-proposals <https://github.com/kubernetes/community/tree/master/contributors/design-proposals>>
>      >
>      >     _______________________________________________
>      >     infinispan-dev mailing list
>      > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>      >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>>
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>     >
>
>     --
>     Tristan Tarrant
>     Infinispan Lead
>     JBoss, a division of Red Hat
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...