Hi all,
Sorry for the delay getting back on this.
The addition of a new component does not worry me so much. It has the advantage of
implementing it once independent of the backend endpoint, whether HR or Rest.
What I'm struggling to understand is what protocol the clients will use to talk to the
router. It seems wasteful having to build two protocols at this level, e.g. one at TCP
level and one at REST level. If you're going to end up building two protocols, the
benefit of the router component dissapears and then you might as well embedded the two
routing protocols within REST and HR directly.
In other words, for the router component to make sense, I think it should:
1. Clients, no matter whether HR or REST, to use 1 single protocol to the router. The
natural thing here would be HTTP/2 or similar protocol.
2. The router then talks HR or REST to the backend. Here the router uses TCP or HTTP
protocol based on the backend needs.
^ The above implies that HR client has to talk TCP when using HR server directly or HTTP/2
when using it via router, but I don't think this is too bad and it gives us some
experience working with HTTP/2 besides the work Anton is carrying out as part of GSoC.
Cheers,
--
Galder Zamarreño
Infinispan, Red Hat
On 11 May 2016, at 10:38, Sebastian Laskawiec
<slaskawi(a)redhat.com> wrote:
Hey Tristan!
If I understood you correctly, you're suggesting to enhance the ProtocolServer to
support multiple EmbeddedCacheManagers (probably with shared transport and by that I mean
started on the same Netty server).
Yes, that also could work but I'm not convinced if we won't loose some
configuration flexibility.
Let's consider a configuration file -
https://gist.github.com/slaskawi/c85105df571eeb56b12752d7f5777ce9, how for example use
authentication for CacheContainer cc1 (and not for cc2) and encryption for cc1 (and not
for cc1)? Both are tied to hotrod-connector. I think using this kind of different options
makes sense in terms of multi tenancy. And please note that if we start a new Netty server
for each CacheContainer - we almost ended up with the router I proposed.
The second argument for using a router is extracting the routing logic into a separate
module. Otherwise we would probably end up with several if(isMultiTenent()) statements in
Hotrod as well as REST server. Extracting this has also additional advantage that we limit
changes in those modules (actually there will be probably 2 changes #1 we should be able
to start a ProtocolServer without starting a Netty server (the Router will do it in multi
tenant configuration) and #2 collect Netty handlers from ProtocolServer).
To sum it up - the router's implementation seems to be more complicated but in the
long run I think it might be worth it.
I also wrote the summary of the above here:
https://github.com/infinispan/infinispan/wiki/Multi-tenancy-for-Hotrod-Se...
@Galder - you wrote a huge part of the Hot Rod server - I would love to hear your opinion
as well.
Thanks
Sebastian
On Tue, May 10, 2016 at 10:59 AM, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
Not sure I like the introduction of another component at the front.
My original idea for allowing the client to choose the container was:
- with TLS: use SNI to choose the container
- without TLS: enhance the PING operation of the Hot Rod protocol to
also take the server name. This would need to be a requirement when
exposing multiple containers over the same endpoint.
From a client API perspective, there would be no difference between the
above two approaches: just specify the server name and depending on the
transport, select the right one.
Tristan
On 29/04/2016 17:29, Sebastian Laskawiec wrote:
> Dear Community,
>
> Please have a look at the design of Multi tenancy support for Infinispan
> [1]. I would be more than happy to get some feedback from you.
>
> Highlights:
>
> * The implementation will be based on a Router (which will be built
> based on Netty)
> * Multiple Hot Rod and REST servers will be attached to the router
> which in turn will be attached to the endpoint
> * The router will operate on a binary protocol when using Hot Rod
> clients and path-based routing when using REST
> * Memcached will be out of scope
> * The router will support SSL+SNI
>
> Thanks
> Sebastian
>
> [1]
>
https://github.com/infinispan/infinispan/wiki/Multi-tenancy-for-Hotrod-Se...
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
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
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