Здравствуйте, e.thrash, Вы писали:
ET>Есть такой код, но почему-то зависает запрос на PostAsync. ET>Ни ошибки, ни результата. В фидлере тоже запроса не видно
ET> var body = "userId=5";
json не валидный.
ET> .PostAsync(url, new StringContent(body, Encoding.UTF8, "application/json"))
ET>>.net core 3.1 ET>>не знаю насколько это влияет что вызов этого метода сервиса идет из юнит теста
vaa>Без этого .ConfigureAwait(false); пробовали?
vaa>в консольном приложении код работает без проблем.
Здравствуйте, e.thrash, Вы писали:
ET>Здравствуйте, vaa, Вы писали:
ET>>>.net core 3.1 ET>>>не знаю насколько это влияет что вызов этого метода сервиса идет из юнит теста
vaa>>Без этого .ConfigureAwait(false); пробовали?
vaa>>в консольном приложении код работает без проблем.
ET>да, вначале без него пробовал. тут ET>начитал
Читал есть нюанс, что все await в цепочке должны быть .ConfigureAwait(false) не помню только внутри Post или в вашем методе.
попробуйте добавить ко всем
var result = await response.Content.ReadAsStringAsync().ConfigureAwait(false);
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, e.thrash, Вы писали:
ET>>Что тут не так?
G>Вызывается как?
Что имеешь ввиду как? конкретно тут напоролся при вызове юнит теста
вот в итоге рабочий код
using (var client = new HttpClient())
{
var url = "http://www.dddd.com";
var body = "user=3";
var response = client.PostAsync(url, new StringContent(body, Encoding.UTF8, "text/plain"))
.Result;
var jsonString = await response.Content.ReadAsStringAsync();
}
но вот почему изначальный код (если отбросить джсон формат) висел и не ошибку не давал и не отрабатывал — загадка.
причем я могу списать на дедлок. Но мне казалось современые фреймворки обнаруживают дедлоки и кидают тоже ошибку
ET>>да, вначале без него пробовал. тут ET>>начитал vaa>Читал есть нюанс, что все await в цепочке должны быть .ConfigureAwait(false) не помню только внутри Post или в вашем методе. vaa>попробуйте добавить ко всем
vaa> var result = await response.Content.ReadAsStringAsync().ConfigureAwait(false);
весело. особенно если цепочка вызовов большая. ненадежно это как-то. сделали бы эксепшн тогда
Здравствуйте, e.thrash, Вы писали:
ET>В постмане результат возвращается. ET>Что тут не так?
Всё так.
Скомпилировал и запустил ваш код, работает без проблем.
Проблема у вас в другом месте.
Пару замечаний:
using System;
using System.Net.Http;
using System.Text;
using System.Threading.Tasks;
async Task<string> GetAsync() // Асинхронные методы принято заканчивать "Async"
{
using (var client = new HttpClient())
{
var url = "http://www.com";
var body = "userId=5";
try
{
var response = await client
.PostAsync(url, new StringContent(body, Encoding.UTF8, "application/json"))
.ConfigureAwait(false);
var result = await response.Content.ReadAsStringAsync();
return result;
}
catch (Exception e)
{
throw; // Не надо явного "throw e" без необходимости. Так мы теряем полный стек исключения
}
}
}
var x = await GetAsync();
Console.WriteLine(x);
Результат
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>openresty/1.13.6.1</center>
</body>
</html>
ConsoleApp1\bin\Debug\net6.0\ConsoleApp1.exe (process 41688) exited with code 0.
Press any key to close this window . . .
Здравствуйте, e.thrash, Вы писали:
ET>вот в итоге рабочий код ET>
ET> using (var client = new HttpClient())
ET> {
ET> var url = "http://www.dddd.com";
ET> var body = "user=3";
ET> var response = client.PostAsync(url, new StringContent(body, Encoding.UTF8, "text/plain"))
ET> .Result;
ET> var jsonString = await response.Content.ReadAsStringAsync();
ET> }
Result блокирует поток исполнения. Под нагрузкой такое нормально не работает. Нужно искать почему не работает вызов с await.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, e.thrash, Вы писали:
ET>>>>Что тут не так?
G>>>Вызывается как?
ET>>Что имеешь ввиду как? конкретно тут напоролся при вызове юнит теста
G>Как вызывается данная функция? Если вызывающий код вызывает .Result\.Wait(), то легко создать дедлок.
G>проблема у вас не в обозначенном коде, а в способе его вызова.
странно, откатился к максимально ранней версии но изначальный код отрабатывает и возвращает 200.
Ощущение что в удаленном сервере была проблема может.
а в PostAsync нет таймаута на ответ? может удаленный сервис подвис и мой тупо ждал пока прочухается
Здравствуйте, e.thrash, Вы писали:
ET>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, e.thrash, Вы писали:
ET>>>>>Что тут не так?
G>>>>Вызывается как?
ET>>>Что имеешь ввиду как? конкретно тут напоролся при вызове юнит теста
G>>Как вызывается данная функция? Если вызывающий код вызывает .Result\.Wait(), то легко создать дедлок.
G>>проблема у вас не в обозначенном коде, а в способе его вызова.
ET>странно, откатился к максимально ранней версии но изначальный код отрабатывает и возвращает 200. ET>Ощущение что в удаленном сервере была проблема может. ET>а в PostAsync нет таймаута на ответ? может удаленный сервис подвис и мой тупо ждал пока прочухается
проверить же легко измените урл. и вообще переходите на 6.0.
Здравствуйте, e.thrash, Вы писали:
ET> а и вопрос, а фреймворк дедлоки разве не умеет обнаруживать и кидать свою ошибку?
Нет. По идее нужно к каждому потоку привязывать предыдущие освобожденные (удерживаемые) WaitHandle и каждому WaitHandle привязывать поток который всех тормозит и те которые ждут.
При ожидании больше какого то времени можно проанализировать кто кого блокирует
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, e.thrash, Вы писали:
ET>Есть такой код, но почему-то зависает запрос на PostAsync. ET>Ни ошибки, ни результата. В фидлере тоже запроса не видно
ET>В постмане результат возвращается. ET>Что тут не так?
касперский не установлен случайно на пк? антихакер иногда блочит.
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, e.thrash, Вы писали:
ET>>Есть такой код, но почему-то зависает запрос на PostAsync. ET>>Ни ошибки, ни результата. В фидлере тоже запроса не видно
ET>>В постмане результат возвращается. ET>>Что тут не так?
vaa>касперский не установлен случайно на пк? антихакер иногда блочит.
симантек. но прям попробую повторить. может реально баг
Здравствуйте, e.thrash, Вы писали:
ET> using (var client = new HttpClient())
Без относительно проблемы, её уже разъяснили.
Хочу указать на еще одну: использование HttpClient в связке с new ну и понятно using. Это ошибка. Может привести к исчерпанию хендлов на процессе (зависит, понятно от частоты и времени непрерывной работы приложения) https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=net-6.0
Почему этот момент не подсвечен красными жирными буквами в доке — не ясно.
> HttpClient is intended to be instantiated once and re-used throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors. Below is an example using HttpClient correctly.
Здравствуйте, vasmann, Вы писали:
V>Здравствуйте, e.thrash, Вы писали:
ET>> using (var client = new HttpClient())
V>Без относительно проблемы, её уже разъяснили. V>Хочу указать на еще одну: использование HttpClient в связке с new ну и понятно using. Это ошибка. Может привести к исчерпанию хендлов на процессе (зависит, понятно от частоты и времени непрерывной работы приложения) V>https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=net-6.0 V>Почему этот момент не подсвечен красными жирными буквами в доке — не ясно.
Почему ошибка использовать using, т.е. dispose это ошибка? Наоборот, раз каждый HttpClient==сокет, то как же иначе?
Здравствуйте, vasmann, Вы писали:
V>Хочу указать на еще одну: использование HttpClient в связке с new ну и понятно using. Это ошибка. Может привести к исчерпанию хендлов на процессе (зависит, понятно от частоты и времени непрерывной работы приложения) V>https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=net-6.0 V>Почему этот момент не подсвечен красными жирными буквами в доке — не ясно.
Ну и вообще может быть полезно пересмотреть подход в пользу HttpClientFactory:
Здравствуйте, Sharov, Вы писали:
S>Почему ошибка использовать using, т.е. dispose это ошибка? Наоборот, раз каждый HttpClient==сокет, то как же иначе?
Сокет — это не managed-ресурс, у него немного другой жизненный цикл. Поэтому Dispose для HttpClient не гарантирует незамедлительного возврата рабочего сокета обратно в пул ОС (linger options и вот это вот всё). А если нету сокетов — нету и паровозиков.
Здравствуйте, Mr.Delphist, Вы писали:
S>>Почему ошибка использовать using, т.е. dispose это ошибка? Наоборот, раз каждый HttpClient==сокет, то как же иначе? MD>Сокет — это не managed-ресурс, у него немного другой жизненный цикл. Поэтому Dispose для HttpClient не гарантирует незамедлительного возврата рабочего сокета обратно в пул ОС (linger options и вот это вот всё). А если нету сокетов — нету и паровозиков.
Я в кусре про разницу. Т.е. фактически тут не будет освобождения сразу, а надо ждать финализатора, т.е. недетерминизм на лицо, верно?
Здравствуйте, Sharov, Вы писали:
S>Я в кусре про разницу. Т.е. фактически тут не будет освобождения сразу, а надо ждать финализатора, т.е. недетерминизм на лицо, верно?
Нет, соединение (и связанный с ним сокет как хендл)будет жить только во время запроса и получения ответа. Когда ответ получен — соединение закроется, хендл освободится.
Т.е. HttpClient не равно Socket, скорее Post/GetAsync — это условно можно назвать тождественны, условно.
Здравствуйте, vasmann, Вы писали:
S>>Я в кусре про разницу. Т.е. фактически тут не будет освобождения сразу, а надо ждать финализатора, т.е. недетерминизм на лицо, верно? V>Нет, соединение (и связанный с ним сокет как хендл)будет жить только во время запроса и получения ответа. Когда ответ получен — соединение закроется, хендл освободится. V>Т.е. HttpClient не равно Socket, скорее Post/GetAsync — это условно можно назвать тождественны, условно.
У меня сессия -- один HttpClient, много сессиий -- много HttpClient'ов. Не так? Если так, то посути HttpClient==socket.
Здравствуйте, Sharov, Вы писали:
S>У меня сессия -- один HttpClient, много сессиий -- много HttpClient'ов. Не так? Если так, то посути HttpClient==socket.
Об этом и говорил. Класс так спроектирован, что подталкивает использовать не корректно. Ровно так и использовали пока не воткнулись как раз в это самое истощение которое указано в документации на класс.
Ответ на твой вопрос: не так? — Да, не так.
Один HttpClient поддерживает много одновременных Post/Send/Get-ов. Выше тут рекомендовали использовать фабрики, или через методы расширения конфигурировать и уже через DI его инжектить в конструктуры нужных классов потребителей.
В общем посмотри документацию, там прям пример есть GoodController — понятно реализован примитивно через статическое поле, но от этого уже можно накрутить любой синглтон который по душе придётся.
Здравствуйте, Sharov, Вы писали:
S>Я в кусре про разницу. Т.е. фактически тут не будет освобождения сразу, а надо ждать финализатора, т.е. недетерминизм на лицо, верно?
Здравствуйте, vasmann, Вы писали:
V> Это ошибка. Может привести к исчерпанию хендлов на процессе (зависит, понятно от частоты и времени непрерывной работы приложения)
Почитал, там нет слов "хендлов", "на процессе".
В ip v4 на один адрес доступно 65K портов. при клиентском соединении выбирается любой свободный.
по v6 не нашел, возможно такое же, но думаю больше.
к тому же время жизни осиротевшего сокета по умолчанию 60 сек.
сколько раз можно вызвать http-запрос с клиента, чтобы такое случилось?
Скорее сервак откажет в обслуживании такого количества запросов.
Впрочем к стартовому вопросу это не имеет отношения.
Согласен только что
Здравствуйте, vaa, Вы писали:
vaa>В ip v4 на один адрес доступно 65K портов. при клиентском соединении выбирается любой свободный. vaa>по v6 не нашел, возможно такое же, но думаю больше.
В протоколе IP нет понятия "порт", т.к. порт — это атрибут транспортного уровня (TCP, UDP, SCTP), а не сетевого (IPv4, IPv6).
Например, в процессе путешествия между отправителем и получателем транспортные пакеты, в зависимости от топологии сети, могут в одном сегменте идти по IPv4, в следующем перепаковаться в IPv6, затем снова IPv4 или даже более сложные варианты со всякими reassembling и т.п. (теоретически, даже через non-IP протокол, если тот обеспечивает должную маршрутизацию). Поэтому лимит портов неизменен.
Далее, про количество доступных портов вообще: несмотря на то, что в теоретический лимит 65К — как и всегда бывает на практике, актуальное число куда меньше.
Часть портов считается "системными", и софт получает отлуп, если не имеет "sudo" или иного админского эквивалента.
При "клиентском соединении" (нулевой bind) порт выдаётся не абы какой, а из динамического пула. Какие там конкретно диапазоны — зависит от версии ОС и прочих настроек, но там запросто может оказаться порядка 15К, всего лишь. Если кажется что это много — утилита типа netstat в помощь. Желательно сразу после ребута, на чистой машине.
vaa>к тому же время жизни осиротевшего сокета по умолчанию 60 сек. vaa>сколько раз можно вызвать http-запрос с клиента, чтобы такое случилось? vaa>Скорее сервак откажет в обслуживании такого количества запросов.
TIME_WAIT is often also known as the 2MSL wait state. This is because the socket that transitions to TIME_WAIT stays there for a period that is 2 x Maximum Segment Lifetime in duration. The MSL is the maximum amount of time that any segment, for all intents and purposes a datagram that forms part of the TCP protocol, can remain valid on the network before being discarded. This time limit is ultimately bounded by the TTL field in the IP datagram that is used to transmit the TCP segment. Different implementations select different values for MSL and common values are 30 seconds, 1 minute or 2 minutes. RFC 793 specifies MSL as 2 minutes and Windows systems default to this value but can be tuned using the TcpTimedWaitDelay registry setting.
Т.е. время полного закрытия всяко больше 60 секунд, если к этому не предпринимать спецусилий.
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, vasmann, Вы писали:
V>> Это ошибка. Может привести к исчерпанию хендлов на процессе (зависит, понятно от частоты и времени непрерывной работы приложения)
vaa>Почитал, там нет слов "хендлов", "на процессе".
Сокет — хендл, ну так было. Может что-то поменяли, но сомневаюсь. Их (сокетов) под 65 тысяч, на деле, для процесса — меньше, потому, что система еще отбирает. При этом это общесистемный ресурс.
vaa>сколько раз можно вызвать http-запрос с клиента, чтобы такое случилось? vaa>Скорее сервак откажет в обслуживании такого количества запросов.
У нас при 4-5 тысячах запросах в секунду начинала возникать ситуация когда ни новые запросы мы отправить не можем, ни клиенты уже не могут подключиться (потому что как и сказал выше — ресурс общий на систему). Выявилась проблема очень быстро, как раз когда "веб апи запросы воткнули без кеширований и прочих ухищрений", исправилась не сразу, потому что и нагрузки были пиковыми — не постоянно 4-5. На саму проблему зашли именно через поддержку — начали поступать жалобы от клиентов, что не могут подключиться, хотя сервер молотил, вроде бы как + были моменты когда сама поддержка не могла зайти на сервер (по той же причине — исчерпались сокеты). При 2-3 запросах в минуту — проблема может и не возникнуть.
Тем не менее ключевое — классы нужно использовать правильно, конкретно HttpClient спроектирован так, что его легко использовать не правильно, а узнать о неправильности можно уже в проде. Хотя достаточно, лично с моей точки зрения, этот аспект в самом начале выделить секцией Warning и жирным текстом подсветить, а не так как сейчас, где-то мимолётом написан GoodController, а перед ним такое мало важное сообщение, что может возникнуть истощение по сокетам — ерунда, какая.
кстати, 65К это же на айпи-адрес, как я понял проблема актуальна для серверных приложений,
на сервер можно поставить несколько интерфейсов, на которые привязать несколько адресов,
единственно не знаю, можно из дотнета управлять с какого интерфейса пойдет запрос.
Здравствуйте, vaa, Вы писали:
vaa>кстати, 65К это же на айпи-адрес, как я понял проблема актуальна для серверных приложений, vaa>на сервер можно поставить несколько интерфейсов, на которые привязать несколько адресов, vaa>единственно не знаю, можно из дотнета управлять с какого интерфейса пойдет запрос.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, vaa, Вы писали:
vaa>>кстати, 65К это же на айпи-адрес, как я понял проблема актуальна для серверных приложений, vaa>>на сервер можно поставить несколько интерфейсов, на которые привязать несколько адресов, vaa>>единственно не знаю, можно из дотнета управлять с какого интерфейса пойдет запрос.
S>http://rsdn.org/forum/network/7787432?tree=tree
