Подтвердить что ты не робот

IIS ASP.NET WebApi Тупик при запросе того же сервера

Мы столкнулись с некоторыми взаимоблокировками при работе с взаимосвязанным ASP.NET WebApis на одном сервере IIS. Мы хотели бы знать, является ли это каким-то ожидаемым поведением из-за размещения всех API-интерфейсов на одном и том же сервере и в том же пуле приложений, поскольку нам удалось избежать проблемы, переместив либо WebApi в другой пул; или если что-то не так с нашим кодом.

Для производства мы, вероятно, будем размещать API на разных серверах или пулах, но мы все же хотим понять, почему это происходит. Наша главная проблема заключается в том, что если это наш ошибочный код, проблема может быть воспроизведена в более широком масштабе, даже если настройка хостинга верна.

Мы создали небольшое решение для воспроизведения тупика, размещенного в GitHub.

Действия воспроизведения следующие:

  • WebClient выполняет несколько запросов HTTP параллельно с WebApi1.
  • WebApi1 выполняет HTTP-запрос к WebApi2.
  • WebApi2 выполняет HTTP-запрос к WebApi3.
  • WebApi3 просто возвращает строку.

Ожидаемое поведение будет заключаться в том, что все запросы в конечном итоге будут разрешены.

Фактическое поведение состоит в том, что некоторые запросы завершаются, а некоторые другие терпят неудачу из-за TaskCancelledException, который, по-видимому, связан с таймингами запросов.

Единственная статья, которую я смог найти, которая, похоже, упоминает ту же проблему, - с 2014 года: " Не отправлять запросы ServerXMLHTTP или WinHTTP к тому же Server", я считаю, что это проблема, с которой мы сталкиваемся, как мы можем подтвердить это?

Контекст

Нам была назначена задача создать централизованный сервер аутентификации для нескольких внутренних API-интерфейсов компании, в которой мы работаем. Мы используем IdentityServer3 со ссылочными токенами, поэтому, когда некоторый API запрашивает второй API с использованием токенов ссылок, второй API будет запрашивать сервер аутентификации для проверки маркера, который воспроизводит проблему.

Я добавил тег IdentityServer, поскольку это может быть распространенной проблемой при передаче нескольких API-интерфейсов и использовании токенов ссылок. Пример в GitHub.

4b9b3361

Ответ 1

Просто одно наблюдение: вы используете HttpClient как статический член для каждого контроллера и согласно this HttpClient не гарантируется, безопасно