(todo lo que se encuentra a continuación inicialmente escrito para .Net 5.0 pero ahora dirigido a .Net 6.0)
Considere este controlador Asp.Net utilizado como REST Api:
[AllowAnonymous] [Route("[controller]")] [ApiController] [ApiConventionType(typeof(DefaultApiConventions))] public class DebugController : ControllerBase { private readonly ILoggingWrapper log; public DebugController(ILoggingWrapper log) { this.log = log; log.Information("Constructor called"); } private async Task Slow() { await Task.Delay(15000).ConfigureAwait(false); } [Authorize()] [HttpGet] [Route("testSlow")] public async Task<ActionResult> TestSlow() { await Slow().ConfigureAwait(false); return Ok(); } [Authorize()] [HttpGet] [Route("testFast")] public async Task<ActionResult> TestFast() { return Ok(); } }Tengo una página de Swagger configurada, donde puedo llamar a TestSlow y TestFast a pedido.
TestSlow El constructor DebugController ingresa inmediatamente, luego TestSlow comienza inmediatamente y regresa después de 15 segundos
TestSlowTestFastDebugController ingresa inmediatamente, luego TestSlow comienza inmediatamenteTestFast , y mientras Testslow aún se está ejecutando, el constructor DebugController ingresa de inmediato y TestFast se inicia de inmediato.las dos experiencias anteriores se comportan como espero: Asp.Net es multiproceso y llamar a un punto final no impide que otro cliente llame a otro punto final, incluso si el primer punto final todavía se está sirviendo al primer cliente.
TestSlowTestSlow allí tambiénDebugController ingresa inmediatamente, luego TestSlow comienza inmediatamenteTestSlow , el constructor del controlador no se llama antes de que la primera llamada a TestSlow haya terminado por completo y haya regresado. . En efecto, las dos llamadas a TestSlow ocurren secuencialmente.¿Porqué es eso? ¿Por qué los subprocesos múltiples parecen "desaparecer" repentinamente en el momento en que intento llamar al mismo punto final dos veces, aunque lo hago desde dos clientes diferentes?
Lo más probable es que descubrí por accidente que el estado de la sesión deshabilita el servicio simultáneo del mismo punto final llamado varias veces, como se ha diseñado aquí:
Deshabilite el estado de sesión por solicitud en ASP.Net MVC
Entonces parece que no es un problema de subprocesos múltiples, sino un problema de configuración de la aplicación web ("por diseño").
@Richard deeming: Publique esto como respuesta y lo marcaré como la correcta.