Adds Grpc.newManagedChannel(String, ChannelCredentials, NameResolverR… #11901
Conversation
netty/src/test/java/io/grpc/netty/UdsNettyChannelProviderTest.java
Outdated
Show resolved
Hide resolved
2. removes visibleForTesting 3. improves the test case
| assertThat(managedChannelBuilder).isNotNull(); | ||
| ManagedChannel channel = managedChannelBuilder.build(); | ||
| assertThat(channel).isNotNull(); | ||
| assertThat(channel.authority()).isEqualTo("/sock.sock"); |
There was a problem hiding this comment.
The test isn't actually working. FakeNameResolverProvider hard-codes the authority to "fake-authority". So this should be failing, because it isn't actually using your NameResolverRegistry.
And that's because the name resolver registry isn't being passed to the ManagedChannelBuilder.
And looking deeper, that's because the NameResolverRegistry code in ManagedChannelRegistry is a bit of a hack; it doesn't coordinate with the ManagedChannelBuilder right now and instead just assumes some later logic in ManagedChannelImpl will produce similar results. It should ideally select the NameResolverProvider and pass it to the ManagedChannelProvider. But I'm not sure how much of that we want to clean up now.
There was a problem hiding this comment.
I think we will need to change the arguments of ManagedChannelProvider.newChannelBuilder(String, ChannelCredentials). That's a bit annoying though, because we can't make that change atomically everywhere (some implementations aren't in this repo) and this is needing to modify an existing code path. So we need to add a new method to ManagedChannelProvider and have it call the existing method by default. We can update all the ManagedChannelProviders in this repo at the same time (and have the old method call the new method). After this change is imported to Google, we'll update the remaining usages and then we can delete the old method.
But I need to think more about what the new signature should look like. There's some interplay between ManagedChannelRegistry and ManagedChannelImplBuilder.getNameResolverProvider(), and it'd be nice to avoid one side assuming the behavior of the other. I also need to figure out whether the NameResolverRegistry will propagate through the channel to LoadBalancer.Helper.createResolvingOobChannel() and getNameResolverRegistry().
There was a problem hiding this comment.
I spoke with Doug, and I think the new signature should have NameResolverProvider (for this channel's use) and NameResolverRegistry (for child channel's use) added as arguments.
To help the migration, you can have the new method call the old method (and just throw away the new arguments).
There was a problem hiding this comment.
Do you mean something like #11978 for migration ?
There was a problem hiding this comment.
The extra method needs to be on ManagedChannelProvider and would be non-static. But the general idea, yeah. We won't let our users pass the NameResolverProvider to io.grpc.Grpc; they'll only pass the registry. Then io.grpc.Grpc will compute the name resolver provider and pass both provider+registry to the selected managed channel provider.
There was a problem hiding this comment.
The update looks good. Why is that a separate PR? What progression of changes are you imagining for this?
There was a problem hiding this comment.
I initially thought that after merging the other PR we could do the migration, because initially i had made changes to expose a new API but after the update that becomes pointless because even if we had merged it, it wouldn't be useful directly.
Fixes #11055
Exposes a new method for channel creation which accepts NameResolverRegistry