That is my recollection as well on DNS-based load balancing. I looked at some other high-profile projects and none seem to really support it specifically and/or in the manner that was done. Thus, use the host list. That seems to be the generally accepted practice.
And you are correct in that there is no workaround other than downgrading (or not upgrading to begin with). Robert Dale On Wed, Nov 6, 2019 at 7:45 AM Stephen Mallette <spmalle...@gmail.com> wrote: > I'm +1 to revert TINKERPOP-2289 as it clearly removed functionality that we > once had and that was not intentional. If we need DNS-based load balancing > then it needs to work in conjunction with what was there before. > Personally, I don't have strong opinion about supporting it or not and if > the host list can work well enough then perhaps users doing DNS-based load > balancing should just utilize that. It's been a while since I've had > anything to do with configuring load balancers but I seem to recall that > DNS-based load balancing isn't an ideal way to implement that piece of your > architecture - perhaps my memory fails me or something has changed but if > there aren't a lot of users taking this approach to solving their load > balancing problems that's another reason to not spend too much energy > trying to implement it for the driver. > > I've commented on TINKERPOP-2289 to get the attention of the person who > brought up this issue in case they have anything they might add to the > discussion. > > In the meantime, I think we may need to get the patch in and form up a > release to fix the problem as this seems like a fairly major issue without > any form of workaround that I'm aware of. > > On Tue, Nov 5, 2019 at 10:48 PM Robert Dale <robd...@gmail.com> wrote: > > > TinkerPop uses WebSocket as the primary transport. WebSocket was > designed > > to ride over and/or be compatible with HTTP. Thus, either by design or > by > > accident, TinkerPop inherits all the features of HTTP. This would > include > > the ability to support HTTP proxies (load balancers), name-based virtual > > hosting, and wildcard SSL certs to name a few. These things are achieved > > through HTTP's Host header. The client sets a Host header to indicate the > > hostname of the service it is attempting to communicate with. So, when > > connecting to dmitry.gremlin.cosmosdb.azure.com, the client sets the > Host > > to dmitry.gremlin.cosmosdb.azure.com. The proxy can read the host > header > > and redirect it to an internal Gremlin Server instance hosting dmitry's > > graph database. Clearly some services have taken advantage of this > > ability. > > > > TINKERPOP-2289 [1] broke this behavior by resolving all hostnames to IP > > address. When the client connects to the service, the Host header is set > > to an IP address instead of a name. The problem is that dmitry, oliver, > > stephen, and 50 million other services all resolve to the same IP address > > [2]. The HTTP proxy has no idea how to route the request (or a poorly > > configured proxy routes them all to a single, default instance). > > > > I think the first action to take is to revert the breaking change in > order > > to restore previous functionality (either by design or by accident). > I've > > created a PR that should restore the previous behavior [3]. > > > > The next action is to discuss what to support. I don't think TinkerPop > > should support DNS-based load balancing in the way implemented in > > TINKERPOP-2289. I'm not sure that it even needs to support it in > general. > > TinkerPop already supports a list of hosts for this purpose. Should > verify > > that IPs work as well. > > > > > > 1. https://issues.apache.org/jira/browse/TINKERPOP-2289 > > 2. > https://groups.google.com/d/msg/gremlin-users/A9rr9jLh5AY/DLguF9QmAQAJ > > 3. https://github.com/apache/tinkerpop/pull/1213 > > > > > > Robert Dale > > >
