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
<ttarrant(a)redhat.com
<mailto:ttarrant@redhat.com>> 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
> <slaskawi(a)redhat.com <mailto:slaskawi@redhat.com>
<mailto:slaskawi@redhat.com <mailto:slaskawi@redhat.com>>> 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-p...
<
https://github.com/kubernetes/community/tree/master/contributors/design-p...
>
<
https://github.com/kubernetes/community/tree/master/contributors/design-p...
<
https://github.com/kubernetes/community/tree/master/contributors/design-p...
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
<mailto:infinispan-dev@lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>>
>
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
> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
>
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
infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
<
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