Совместимость Flurl с .net core 2.1

У HttpClient не было проблем с параллелизмом. Если вы столкнулись с проблемами параллелизма, объясните реальную проблему, чтобы люди могли помочь. На самом деле HttpClient с самого начала был потокобезопасным, и вы могли (должны) использовать один экземпляр для нескольких вызовов. Он был асинхронным с самого начала, что означает, что вам не нужно было блокировать при его использовании. Возможно, вы используете .Wait() или .Result?   -  person Panagiotis Kanavos    schedule 25.06.2018

На самом деле это выглядит так: github.com/dotnet/corefx/issues/14897 и github.com/dotnet/corefx/issues/30040 я столкнулся с этим при выполнении нагрузочное тестирование. И на самом деле я помню, что это было с x4.1   -  person Vytautas Pranskunas    schedule 25.06.2018

Кстати: как Result влияет на параллелизм?   -  person Vytautas Pranskunas    schedule 25.06.2018

Проблемы, на которые вы ссылаетесь, не показывают никаких ошибок параллелизма - первая - это старая, исправленная ошибка, которая была ошибочно повторно открыта людьми, которые предположили, что она связана с их проблемами. Второй был фактически закрыт как несвязанный. Единственная реальная проблема вообще не была связана с параллелизмом.   -  person Panagiotis Kanavos    schedule 25.06.2018

Что касается .Result, то он блокирует вызов, что означает, что вы теряете параллелизм. Если вы используете .Result в своем коде, вы вполне можете блокировать себя. В любом случае, без кода, показывающего, в чем проблема, невозможно помочь или даже догадаться, что не так.   -  person Panagiotis Kanavos    schedule 25.06.2018

Кстати, проблема, на которую вы ссылались, вообще не имеет ничего общего с параллелизмом. сервер вернул тело ответа HTTP HEAD, которое по определению не должно иметь тела. Если вы не сделали запрос HEAD, связанная проблема не имеет отношения   -  person Panagiotis Kanavos    schedule 25.06.2018

Затем я неправильно понял это, потому что при чтении всех сообщений где-то упоминалось, что это из-за параллелизма WinHttp. Но в любом случае это не отвечает на мой первоначальный вопрос - использует ли Flurl новый HttpClient из .NET core 2.1 или нет?   -  person Vytautas Pranskunas    schedule 25.06.2018

Это ответ на вопрос - это не имеет значения. Во-первых, любая проблема, с которой вы столкнулись, не имеет ничего общего с предполагаемыми проблемами параллелизма HttpClient. Если бы они существовали, тысячи разработчиков заметили бы это много лет назад. WinHTTP — это библиотека операционной системы, используемая также и полной структурой.   -  person Panagiotis Kanavos    schedule 25.06.2018

Во-вторых, среда выполнения приложения, которая предоставляет версию HttpClient по умолчанию. Если ваше приложение нацелено на 2.1, вы получите новый HttpClient. Вы можете установить более новые версии, установив более новую версию пакета NuGet HttpClient. Это не решит никаких проблем в вашем коде или библиотеке.   -  person Panagiotis Kanavos    schedule 25.06.2018

Панайотис Канавос: Действительно, когда я перенес код на ядро ​​2.1, не было ни одного неудачного запроса (из 5000), выполняющего тот же нагрузочный тест. Итак, проблема ушла. p.s. в коде не было миров ожидания или результата   -  person Vytautas Pranskunas    schedule 28.06.2018

Какая проблема? Вы так и не объяснили, в чем проблема. Ссылки, которые вы разместили в комментариях, не связаны с какими-либо проблемами параллелизма, они касались неправильных ответов сервера. Возможно, HttpClient теперь игнорирует недопустимые тела в запросах, которые не должны иметь тела, такого как HEAD, вместо того, чтобы бросать. У вас есть код? Стек вызовов исключений? Захват скрипача?   -  person Panagiotis Kanavos    schedule 28.06.2018

У меня пока нет скрипача. Но проблема заключалась в том, что каждый сотый или около того запрос приходил, как ошибка, вызывающая точно такое же исключение, как в тех двух ссылках, которые я разместил. Но я могу заверить, что никакая часть кода не отправляет HEAD. System.Net.Http.WinHttpException: сервер вернул недопустимый или непризнанный ответ   -  person Vytautas Pranskunas    schedule 28.06.2018

Это означает, что сервер вернул неверный ответ. Это не имеет ничего общего с HttpClient. Вот в чем была проблема со связанными вопросами, поэтому они были закрыты.   -  person Panagiotis Kanavos    schedule 28.06.2018

Кстати, я использую HttpClient для выполнения тысяч запросов в день пакетами. Если бы были какие-либо проблемы с параллелизмом, я бы заметил. Что я заметил, так это сбой серверов, если я делаю слишком много запросов одновременно, поэтому я использую регулирование, чтобы делать только, например, 10 или 20 запросов за раз.   -  person Panagiotis Kanavos    schedule 28.06.2018

Вместо того, чтобы предполагать, что обновление до версии 2.1 решило проблему, я предлагаю вам настроить SocketHttpHandler для ограничения количества одновременных подключений. Добавьте также обработку исключений и регистрируйте полное исключение, а не только сообщение. Полное исключение, вероятно, будет содержать ответ. В любом случае вы можете проверить ответ в обработчике исключений. Вызовы HTTP все время терпят неудачу, вам нужно иметь возможность проверить, была ли это ошибка 4xx (ваша ошибка), 5xx (ошибка сервера) или соединение прервалось.   -  person Panagiotis Kanavos    schedule 28.06.2018

Наконец, рассмотрите возможность добавления Полли, как описано Скоттом Ханслеманом в разделе Добавление устойчивости и обработки временных сбоев в .NET Core. HttpClient с Полли. Это позволит вам настроить, например, повторные попытки с задержкой для некоторых сбоев или отсрочкой на 1 минуту, если одновременно возникает слишком много ошибок и т. д.   -  person Panagiotis Kanavos    schedule 28.06.2018

Спасибо за полезную информацию, я постараюсь применить эти методы.   -  person Vytautas Pranskunas    schedule 29.06.2018