Re: [infinispan-dev] Multi tenancy support for Infinispan

Hey Anton! Just to clarify - the router is a concept implemented in Infinispan *Server*. In the endpoint to be 100% precise. Each server will have this component up and running and it will take the incomming TCP connection and pass it to proper NettyServer or RestServer instance (after choosing

Re: [infinispan-dev] Multi tenancy support for Infinispan

Sebastian, correct me if I'm wrong. As I understand, client will have Router instance, which has info about servers, caches in these servers and support protocols (HotRod, HTTP/1, HTTP/2). So, I have some questions: 1) Will Router keep all connections up or close connection after the request?

Re: [infinispan-dev] Multi tenancy support for Infinispan

Hey! Dan pointed out a very interesting thing [1] - we could use host header for multi-tenant REST endpoints. Although I really like the idea (this header was introduced to support this kind of use cases), it might be a bit problematic from security point of view (if someone forgets to set it,

Re: [infinispan-dev] Multi tenancy support for Infinispan

Hey! The multi-tenancy support for Hot Rod and REST has been implemented [2]. Since the PR is gigantic, I marked some interesting places for review so you might want to skip boilerplate parts. The Memcached and WebSockets implementations are currently out of scope. If you would like us to

Re: [infinispan-dev] Multi tenancy support for Infinispan

Hey Galder! Comments inlined. Thanks Sebastian On Wed, May 25, 2016 at 10:52 AM, Galder Zamarreño wrote: > 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

Re: [infinispan-dev] Multi tenancy support for Infinispan

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

Re: [infinispan-dev] Multi tenancy support for Infinispan

Hey Sanne! Comments inlined. Thanks Sebastian On Sun, May 15, 2016 at 11:27 PM, Sanne Grinovero wrote: > Hi Sebastian, > > the design seems to assume that what people want is to have multiple > cache containers, one per tenant. > Did you consider the tradeoffs comparing

Re: [infinispan-dev] Multi tenancy support for Infinispan

Hi Sebastian, the design seems to assume that what people want is to have multiple cache containers, one per tenant. Did you consider the tradeoffs comparing to a solution in which you have a single cache container to manage all caches, but isolate tenants by having each one access only the

Re: [infinispan-dev] Multi tenancy support for Infinispan

Hey guys! Any last call on this? I'm going to start the implementation on Monday. Thanks Sebastian On Wed, May 11, 2016 at 10:38 AM, Sebastian Laskawiec wrote: > Hey Tristan! > > If I understood you correctly, you're suggesting to enhance the > ProtocolServer to support

Re: [infinispan-dev] Multi tenancy support for Infinispan

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

Re: [infinispan-dev] Multi tenancy support for Infinispan

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

Re: [infinispan-dev] Multi tenancy support for Infinispan

On Mon, May 9, 2016 at 3:30 PM, Radim Vansa wrote: > So you can initiate connection with SSL (+SNI) and then downgrade it to > plain-text? > No, that's not possible. SNI Host Name is used to match proper certificate from KeyStore. After successful handshake, you communicate

Re: [infinispan-dev] Multi tenancy support for Infinispan

On 05/09/2016 07:52 AM, Sebastian Laskawiec wrote: > Hey Radim! > > Comments inlined. > > Thanks > Sebastian > > On Mon, May 9, 2016 at 12:55 PM, Radim Vansa > wrote: > > As for the questions: > * Is SSL required for SNI? I can imagine that

Re: [infinispan-dev] Multi tenancy support for Infinispan

Hey Radim! Comments inlined. Thanks Sebastian On Mon, May 9, 2016 at 12:55 PM, Radim Vansa wrote: > As for the questions: > * Is SSL required for SNI? I can imagine that multi-tenancy would make > sense even in situations when the connection does not need to be > encrypted.

Re: [infinispan-dev] Multi tenancy support for Infinispan

As for the questions: * Is SSL required for SNI? I can imagine that multi-tenancy would make sense even in situations when the connection does not need to be encrypted. Moreover, if we plan to eventually have HR clients with async API (and using async I/O), SSL is even more PITA. Btw., do we

Re: [infinispan-dev] Multi tenancy support for Infinispan

Hey Emmanuel! Comments inlined. There is one more thing to discuss - how SNI [1] for Hotrod server fits into the Router design. Obviously there is some overlap and the for SSL+SNI needs to be also implemented in the Router [2] (it potentially needs to decrypt an encrypted "switch-to-tenant"

Re: [infinispan-dev] Multi tenancy support for Infinispan

Is the router a software component of all nodes in the cluster ? Does the router then redirect all request to the same cache-container for all tenant? How is the isolation done then? Or does each tenant have effectively different cache containers and thus be "physically" isolated? Or is that

[infinispan-dev] Multi tenancy support for Infinispan

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