netty5/resolver-dns/src/main/java/io/netty/resolver/dns/RoundRobinDnsAddressResolverGroup.java

69 lines
2.8 KiB
Java
Raw Normal View History

Support aggressive round-robin dns Motivation: Suppose the domain `foo.example.com` resolves to the following ip addresses `10.0.0.1`, `10.0.0.2`, `10.0.0.3`. Round robin DNS works by having each client probabilistically getting a different ordering of the set of target IP’s, so connections from different clients (across the world) would be split up across each of the addresses. Example: In a `ChannelPool` to manage connections to `foo.example.com`, it may be desirable for high QPS applications to spread the requests across all available network addresses. Currently, Netty’s resolver would return only the first address (`10.0.0.1`) to use. Let say we are making dozens of connections. The name would be resolved to a single IP and all of the connections would be made to `10.0.0.1`. The other two addresses would not see any connections. (they may see it later if new connections are made and `10.0.0.2` is the first in the list at that time of a subsequent resolution). In these changes, I add support to select a random one of the resolved addresses to use on each resolve call, all while leveraging the existing caching and inflight request detection. This way in my example, the connections would be make to random selections of the resolved IP addresses. Modifications: I added another method `newAddressResolver` to `DnsAddressResolverGroup` which can be overriden much like `newNameResolver`. The current functionality which creates `InetSocketAddressResolver` is still used. I added `RoundRobinDnsAddressResolverGroup` which extends DnsAddressResolverGroup and overrides the `newAddressResolver` method to return a subclass of the `InetSocketAddressResolver`. This subclass is called `RoundRobinInetSocketAddressResolver` and it contains logic that takes a `resolve` request, does a `resolveAll` under the hood, and returns a single element at random from the result of the `resolveAll`. Result: The existing functionality of `DnsAddressResolverGroup` is left unchanged. All new functionality is in the `RoundRobinInetSocketAddressResolver` which users will now have the option to use.
2016-09-27 02:45:41 +02:00
/*
* Copyright 2016 The Netty Project
*
* The Netty Project licenses this file to you under the Apache License,
* version 2.0 (the "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations
* under the License.
*/
package io.netty.resolver.dns;
import io.netty.channel.ChannelFactory;
import io.netty.channel.EventLoop;
import io.netty.channel.socket.DatagramChannel;
import io.netty.resolver.AddressResolver;
import io.netty.resolver.AddressResolverGroup;
import io.netty.resolver.NameResolver;
import io.netty.resolver.RoundRobinInetAddressResolver;
Support aggressive round-robin dns Motivation: Suppose the domain `foo.example.com` resolves to the following ip addresses `10.0.0.1`, `10.0.0.2`, `10.0.0.3`. Round robin DNS works by having each client probabilistically getting a different ordering of the set of target IP’s, so connections from different clients (across the world) would be split up across each of the addresses. Example: In a `ChannelPool` to manage connections to `foo.example.com`, it may be desirable for high QPS applications to spread the requests across all available network addresses. Currently, Netty’s resolver would return only the first address (`10.0.0.1`) to use. Let say we are making dozens of connections. The name would be resolved to a single IP and all of the connections would be made to `10.0.0.1`. The other two addresses would not see any connections. (they may see it later if new connections are made and `10.0.0.2` is the first in the list at that time of a subsequent resolution). In these changes, I add support to select a random one of the resolved addresses to use on each resolve call, all while leveraging the existing caching and inflight request detection. This way in my example, the connections would be make to random selections of the resolved IP addresses. Modifications: I added another method `newAddressResolver` to `DnsAddressResolverGroup` which can be overriden much like `newNameResolver`. The current functionality which creates `InetSocketAddressResolver` is still used. I added `RoundRobinDnsAddressResolverGroup` which extends DnsAddressResolverGroup and overrides the `newAddressResolver` method to return a subclass of the `InetSocketAddressResolver`. This subclass is called `RoundRobinInetSocketAddressResolver` and it contains logic that takes a `resolve` request, does a `resolveAll` under the hood, and returns a single element at random from the result of the `resolveAll`. Result: The existing functionality of `DnsAddressResolverGroup` is left unchanged. All new functionality is in the `RoundRobinInetSocketAddressResolver` which users will now have the option to use.
2016-09-27 02:45:41 +02:00
import io.netty.util.internal.UnstableApi;
import java.net.InetAddress;
import java.net.InetSocketAddress;
/**
* A {@link AddressResolverGroup} of {@link DnsNameResolver}s that supports random selection of destination addresses if
* multiple are provided by the nameserver. This is ideal for use in applications that use a pool of connections, for
* which connecting to a single resolved address would be inefficient.
*/
@UnstableApi
public class RoundRobinDnsAddressResolverGroup extends DnsAddressResolverGroup {
public RoundRobinDnsAddressResolverGroup(DnsNameResolverBuilder dnsResolverBuilder) {
super(dnsResolverBuilder);
}
Support aggressive round-robin dns Motivation: Suppose the domain `foo.example.com` resolves to the following ip addresses `10.0.0.1`, `10.0.0.2`, `10.0.0.3`. Round robin DNS works by having each client probabilistically getting a different ordering of the set of target IP’s, so connections from different clients (across the world) would be split up across each of the addresses. Example: In a `ChannelPool` to manage connections to `foo.example.com`, it may be desirable for high QPS applications to spread the requests across all available network addresses. Currently, Netty’s resolver would return only the first address (`10.0.0.1`) to use. Let say we are making dozens of connections. The name would be resolved to a single IP and all of the connections would be made to `10.0.0.1`. The other two addresses would not see any connections. (they may see it later if new connections are made and `10.0.0.2` is the first in the list at that time of a subsequent resolution). In these changes, I add support to select a random one of the resolved addresses to use on each resolve call, all while leveraging the existing caching and inflight request detection. This way in my example, the connections would be make to random selections of the resolved IP addresses. Modifications: I added another method `newAddressResolver` to `DnsAddressResolverGroup` which can be overriden much like `newNameResolver`. The current functionality which creates `InetSocketAddressResolver` is still used. I added `RoundRobinDnsAddressResolverGroup` which extends DnsAddressResolverGroup and overrides the `newAddressResolver` method to return a subclass of the `InetSocketAddressResolver`. This subclass is called `RoundRobinInetSocketAddressResolver` and it contains logic that takes a `resolve` request, does a `resolveAll` under the hood, and returns a single element at random from the result of the `resolveAll`. Result: The existing functionality of `DnsAddressResolverGroup` is left unchanged. All new functionality is in the `RoundRobinInetSocketAddressResolver` which users will now have the option to use.
2016-09-27 02:45:41 +02:00
public RoundRobinDnsAddressResolverGroup(
Class<? extends DatagramChannel> channelType,
DnsServerAddressStreamProvider nameServerProvider) {
super(channelType, nameServerProvider);
Support aggressive round-robin dns Motivation: Suppose the domain `foo.example.com` resolves to the following ip addresses `10.0.0.1`, `10.0.0.2`, `10.0.0.3`. Round robin DNS works by having each client probabilistically getting a different ordering of the set of target IP’s, so connections from different clients (across the world) would be split up across each of the addresses. Example: In a `ChannelPool` to manage connections to `foo.example.com`, it may be desirable for high QPS applications to spread the requests across all available network addresses. Currently, Netty’s resolver would return only the first address (`10.0.0.1`) to use. Let say we are making dozens of connections. The name would be resolved to a single IP and all of the connections would be made to `10.0.0.1`. The other two addresses would not see any connections. (they may see it later if new connections are made and `10.0.0.2` is the first in the list at that time of a subsequent resolution). In these changes, I add support to select a random one of the resolved addresses to use on each resolve call, all while leveraging the existing caching and inflight request detection. This way in my example, the connections would be make to random selections of the resolved IP addresses. Modifications: I added another method `newAddressResolver` to `DnsAddressResolverGroup` which can be overriden much like `newNameResolver`. The current functionality which creates `InetSocketAddressResolver` is still used. I added `RoundRobinDnsAddressResolverGroup` which extends DnsAddressResolverGroup and overrides the `newAddressResolver` method to return a subclass of the `InetSocketAddressResolver`. This subclass is called `RoundRobinInetSocketAddressResolver` and it contains logic that takes a `resolve` request, does a `resolveAll` under the hood, and returns a single element at random from the result of the `resolveAll`. Result: The existing functionality of `DnsAddressResolverGroup` is left unchanged. All new functionality is in the `RoundRobinInetSocketAddressResolver` which users will now have the option to use.
2016-09-27 02:45:41 +02:00
}
public RoundRobinDnsAddressResolverGroup(
ChannelFactory<? extends DatagramChannel> channelFactory,
DnsServerAddressStreamProvider nameServerProvider) {
super(channelFactory, nameServerProvider);
Support aggressive round-robin dns Motivation: Suppose the domain `foo.example.com` resolves to the following ip addresses `10.0.0.1`, `10.0.0.2`, `10.0.0.3`. Round robin DNS works by having each client probabilistically getting a different ordering of the set of target IP’s, so connections from different clients (across the world) would be split up across each of the addresses. Example: In a `ChannelPool` to manage connections to `foo.example.com`, it may be desirable for high QPS applications to spread the requests across all available network addresses. Currently, Netty’s resolver would return only the first address (`10.0.0.1`) to use. Let say we are making dozens of connections. The name would be resolved to a single IP and all of the connections would be made to `10.0.0.1`. The other two addresses would not see any connections. (they may see it later if new connections are made and `10.0.0.2` is the first in the list at that time of a subsequent resolution). In these changes, I add support to select a random one of the resolved addresses to use on each resolve call, all while leveraging the existing caching and inflight request detection. This way in my example, the connections would be make to random selections of the resolved IP addresses. Modifications: I added another method `newAddressResolver` to `DnsAddressResolverGroup` which can be overriden much like `newNameResolver`. The current functionality which creates `InetSocketAddressResolver` is still used. I added `RoundRobinDnsAddressResolverGroup` which extends DnsAddressResolverGroup and overrides the `newAddressResolver` method to return a subclass of the `InetSocketAddressResolver`. This subclass is called `RoundRobinInetSocketAddressResolver` and it contains logic that takes a `resolve` request, does a `resolveAll` under the hood, and returns a single element at random from the result of the `resolveAll`. Result: The existing functionality of `DnsAddressResolverGroup` is left unchanged. All new functionality is in the `RoundRobinInetSocketAddressResolver` which users will now have the option to use.
2016-09-27 02:45:41 +02:00
}
/**
* We need to override this method, not
* {@link #newNameResolver(EventLoop, ChannelFactory, DnsServerAddressStreamProvider)},
* because we need to eliminate possible caching of {@link io.netty.resolver.NameResolver#resolve}
* by {@link InflightNameResolver} created in
* {@link #newResolver(EventLoop, ChannelFactory, DnsServerAddressStreamProvider)}.
*/
Support aggressive round-robin dns Motivation: Suppose the domain `foo.example.com` resolves to the following ip addresses `10.0.0.1`, `10.0.0.2`, `10.0.0.3`. Round robin DNS works by having each client probabilistically getting a different ordering of the set of target IP’s, so connections from different clients (across the world) would be split up across each of the addresses. Example: In a `ChannelPool` to manage connections to `foo.example.com`, it may be desirable for high QPS applications to spread the requests across all available network addresses. Currently, Netty’s resolver would return only the first address (`10.0.0.1`) to use. Let say we are making dozens of connections. The name would be resolved to a single IP and all of the connections would be made to `10.0.0.1`. The other two addresses would not see any connections. (they may see it later if new connections are made and `10.0.0.2` is the first in the list at that time of a subsequent resolution). In these changes, I add support to select a random one of the resolved addresses to use on each resolve call, all while leveraging the existing caching and inflight request detection. This way in my example, the connections would be make to random selections of the resolved IP addresses. Modifications: I added another method `newAddressResolver` to `DnsAddressResolverGroup` which can be overriden much like `newNameResolver`. The current functionality which creates `InetSocketAddressResolver` is still used. I added `RoundRobinDnsAddressResolverGroup` which extends DnsAddressResolverGroup and overrides the `newAddressResolver` method to return a subclass of the `InetSocketAddressResolver`. This subclass is called `RoundRobinInetSocketAddressResolver` and it contains logic that takes a `resolve` request, does a `resolveAll` under the hood, and returns a single element at random from the result of the `resolveAll`. Result: The existing functionality of `DnsAddressResolverGroup` is left unchanged. All new functionality is in the `RoundRobinInetSocketAddressResolver` which users will now have the option to use.
2016-09-27 02:45:41 +02:00
@Override
protected final AddressResolver<InetSocketAddress> newAddressResolver(EventLoop eventLoop,
NameResolver<InetAddress> resolver)
throws Exception {
return new RoundRobinInetAddressResolver(eventLoop, resolver).asAddressResolver();
Support aggressive round-robin dns Motivation: Suppose the domain `foo.example.com` resolves to the following ip addresses `10.0.0.1`, `10.0.0.2`, `10.0.0.3`. Round robin DNS works by having each client probabilistically getting a different ordering of the set of target IP’s, so connections from different clients (across the world) would be split up across each of the addresses. Example: In a `ChannelPool` to manage connections to `foo.example.com`, it may be desirable for high QPS applications to spread the requests across all available network addresses. Currently, Netty’s resolver would return only the first address (`10.0.0.1`) to use. Let say we are making dozens of connections. The name would be resolved to a single IP and all of the connections would be made to `10.0.0.1`. The other two addresses would not see any connections. (they may see it later if new connections are made and `10.0.0.2` is the first in the list at that time of a subsequent resolution). In these changes, I add support to select a random one of the resolved addresses to use on each resolve call, all while leveraging the existing caching and inflight request detection. This way in my example, the connections would be make to random selections of the resolved IP addresses. Modifications: I added another method `newAddressResolver` to `DnsAddressResolverGroup` which can be overriden much like `newNameResolver`. The current functionality which creates `InetSocketAddressResolver` is still used. I added `RoundRobinDnsAddressResolverGroup` which extends DnsAddressResolverGroup and overrides the `newAddressResolver` method to return a subclass of the `InetSocketAddressResolver`. This subclass is called `RoundRobinInetSocketAddressResolver` and it contains logic that takes a `resolve` request, does a `resolveAll` under the hood, and returns a single element at random from the result of the `resolveAll`. Result: The existing functionality of `DnsAddressResolverGroup` is left unchanged. All new functionality is in the `RoundRobinInetSocketAddressResolver` which users will now have the option to use.
2016-09-27 02:45:41 +02:00
}
}