Well, we did revert the change as discussed in this thread - you can see that here:
https://github.com/apache/tinkerpop/pull/1213 and it will be part of the 3.3.10 and 3.4.5 releases which are scheduled to be published in about two weeks. On Wed, Jan 22, 2020 at 2:40 PM Oliver Towers <[email protected]> wrote: > Reviving this thread. > > Cosmos DB team has received a few bug reports about the original IP > connectivity issue from customers who picked up 3.4.4 and 3.3.9 release for > gremlin console. > > It looks like a patch for 3.4.4 and 3.3.9 was not started, so I wanted to > find out what the process is for requesting a patch for these releases? > > - Oliver Towers > > On 2019/11/07 00:01:39, Robert Dale <[email protected]> wrote: > > 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 <[email protected]> > > 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 <[email protected]> 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 > > > > > > > > > >
