Будет ли это использование FlUrl управлять изменениями DNS - PullRequest
Новая
       58

Будет ли это использование FlUrl управлять изменениями DNS

0 голосов
/ 17 октября 2019

В .net core 2.1 я использую библиотеку Flurl, чтобы предотвратить известную проблему исчерпания сокета HttpClient. Поскольку я использую устаревшее программное обеспечение, мы не можем использовать инъекцию DI. Итак, я делаю что-то очень простое, как это: 

var responseMessage = await url.PostAsync(content);

В документации сказано:

Свободные методы, подобные этому, будут лениво создавать HTTP-клиента, кэшировать его,и возобновить его для каждого звонка на один и тот же хост:

Однако я не могу найти никакой информации о возможных изменениях DNS. Поскольку он использует кеширование, управляет ли DNS изменениями библиотеки? Если нет, как я могу отслеживать изменения DNS, а также предотвращать проблему исчерпания сокета?

1 Ответ

0 голосов
/ 17 октября 2019

Flurl имеет возможность периодически располагать / воссоздавать базовые HttpClient экземпляры через глобальную конфигурацию (выполняется при запуске приложения): 

FlurlHttp.Configure(settings => settings.ConnectionLeaseTimeout = TimeSpan.FromMinutes(2));

Это похоже на популярное решение дляПроблема DNS , которая использует .NET Framework ServicePointManager.ConnectionLeaseTimeout, за исключением того, что она работает на всех платформах.

Альтернативой, представленной в .NET Core 2.1, является использование довольно плохо документированного SocketsHttpHandler.PooledConnectionLifetime . Это рекомендуемое решение для .NET Core, и Flurl может подключиться к нему с помощью собственной фабрики: 

public class ConnectionLifetimeHttpClientFactory : DefaultHttpClientFactory
{
    public override HttpMessageHandler CreateMessageHandler()
    {
        return new SocketsHttpHandler {
            PooledConnectionLifetime = TimeSpan.FromMinutes(2);
        };
    }
}

Затем зарегистрировать его при запуске: 

FlurlHttp.Configure(settings =>
    settings.HttpClientFactory = new ConnectionLifetimeHttpClientFactory());

В качестве предупреждения, я на самом деле не проверял это, но он должен работать, и я, вероятно, рекомендую его немного по сравнению с первым вариантом, так как он задействует более функциональные возможности платформы и поэтому, вероятно, немного более эффективен.

...