Dans mon application ASP.NET Core, j'ai une action apparemment très simple. Il attend une valeur à partir d'une méthode asynchrone, puis retourne comme OK résultat:Strange situation de blocage dans ASP.NET Core Controller
public async Task<IActionResult> GetNextCommand()
{
var command = await LongPollManager.Instance.GetNextCommand(HttpContext.RequestAborted);
return Ok(command);
}
Quand j'appelle cette route avec un certain client HTTP je peux vérifier dans le débogueur que cette méthode asynchrone retourne la valeur souhaitée et passe à la méthode Ok:
Si je laisse le débogueur continuer j'attendre pour obtenir le résultat dans mon client HTTP. Mais le client ne reçoit jamais de réponse.
Lorsque je brise ensuite le débogueur, je peux voir que le thread est bloqué sur un verrou interne. Vous pouvez le voir dans la capture d'écran actuelle:
Ce comportement peut être vu que depuis que je fait quelques changements dans ma LongPollManager
classe (qui est en fait assez complexe et utilise TaskCompletionSource
s et ConcurrentDictionarie
s, et SemaphoreSlim
s intérieurement). Ce qui me laisse perplexe, c'est que ce n'est pas ma méthode GetNextCommand
qui bloque, mais le blocage semble se produire dans ASP.NET Core. Une fois que l'exécution est à la ligne 29 et j'ai reçu mon objet command
, tous les trucs asynchrones compliqués de ma classe LongPollManager
sont terminés et je ne vois pas comment tout ce que je change dans LongPollManager
peut empêcher ASP.NET Core de terminer correctement la requête.
Que peut-on attendre d'ASP.NET Core? Comment mon code (qui court vers la ligne 29 sans blocage) peut-il provoquer une telle situation de blocage?
Comment le client appelle-t-il – Nkosi
Le client est un autre processus sur la même machine effectuant un HTTP GET sur cette route. –
Le modèle renvoyé est-il un objet POCO ou des effets d'invocation sont-ils invoqués lors de la sérialisation? – Nkosi