On Fri, Jun 30, 2017 at 12:41 PM, Dave Fisher <dave2w...@comcast.net> wrote:
> So I am clear the problem is having an SSL endpoint that authenticates the > client and allows the messages to flow through to the correct broker. > The main problem this proposal is trying to solve is how to expose Pulsar, which is a stateful service [1], through a stateless frontend. The reason to have a stateless frontend, is that it's much easier to give access to this service from outside the current cluster/datacenter. If you have a stateless service, you can easily use multiple strategies (VIP, DNS, ....) to expose multiple instances that are composing the service and you don't need to connect to specific nodes. Any node, as routed by the VIP/DNS/.. mechanism will work. One example of this is when deploying in a cloud environment, especially with some container orchestration mechanism like kubernetes. If you want to connect and publish messages from outside the Kubernetes cluster (or from outside the cloud region alltogether), having the stateless service, exposed to a cloud specific load balancer, makes it a lot easier to deploy and to control the access from the outside world. For the SSL part, right now in Pulsar you might want to use TLS/SSL for few reasons: 1. Transport encryption 2. Broker authentication (validate the broker we're talking to is legitimate) 3. Client authentication (extract the client principal to be used for authorization) All these 3 should continue to work even when a proxy is introduced. In particular, for the client authentication, the proxy is responsible of validating the authentication and then carry the client principal over to the broker. >> Can I assume that if the broker disconnects that the requirement is for the client to reconnect and then at that point get the new broker? Correct, that's the behavior of the client library and it will not change. Whenever the connection breaks, the client library internally tries to re-do the topic lookup (because now it might have moved to a different broker) and reconnect, with exponential backoff, until it succeeds. [1] brokers don't keep state on disk, but still a topic is only assign to a single broker at a give point in time. -- Matteo Merli <matteo.me...@gmail.com>