IIS ASP.NET WebApi Deadlock al solicitar el mismo servidor
asp.net-web-api2 identityserver3 (1)
Hemos estado experimentando algunos bloqueos cuando trabajamos con ASP.NET WebApis interconectado en el mismo servidor IIS. Nos gustaría saber si esto es de alguna manera un comportamiento esperado, debido al alojamiento de todas las API en el mismo servidor y el mismo grupo de aplicaciones, ya que hemos logrado evitar el problema al mover cualquiera de los dos a un grupo diferente; o si hay algo mal con nuestro código.
Para la producción, probablemente alojaremos las API en diferentes servidores o grupos, pero aun así nos gustaría entender por qué sucede esto. Nuestra principal preocupación es que, si es nuestro código defectuoso, el problema puede reproducirse en una escala mayor, incluso si la configuración de alojamiento es correcta.
Hemos creado una pequeña solución para reproducir el punto muerto alojado en GitHub .
Los pasos de reproducción son los siguientes:
- WebClient ejecuta múltiples solicitudes HTTP en paralelo WebApi1.
- WebApi1 ejecuta una solicitud HTTP a WebApi2.
- WebApi2 ejecuta una solicitud HTTP a WebApi3.
- WebApi3 simplemente devuelve una cadena.
El comportamiento esperado sería que todas las solicitudes finalmente se resuelvan.
El comportamiento real es que ciertas solicitudes se completan, mientras que otras fallan, debido a una TaskCancelledException que parece deberse a que las solicitudes se agotan.
El único artículo que pude encontrar que parece mencionar el mismo problema es el 2014: " No envíe solicitudes ServerXMLHTTP o WinHTTP al mismo servidor ", creo que este es el problema que estamos experimentando, ¿cómo podemos confirmar esto? ?
Contexto
Se nos ha asignado la tarea de crear un servidor de autenticación centralizado para múltiples API internas de la empresa en la que trabajamos. Estamos utilizando IdentityServer3 con tokens de referencia, por lo que cuando alguna API solicita una segunda API utilizando tokens de referencia, la segunda API solicitará al servidor de autenticación la validación de tokens que reproduce el problema.
He agregado la etiqueta IdentityServer, ya que esto podría ser un problema común al hacer múltiples comunicaciones de API y usar tokens de referencia. Muestra en GitHub .
Solo una observación: está utilizando HttpClient como un miembro estático para cada Controlador y, de acuerdo con esto, no se garantiza que HttpClient sea seguro para subprocesos