La méthode Web API Controller s'exécute à la fin. Aucune réponse HTTP. Hangs

Question

Je suis à la recherche d'une approche pour déboguer ce scénario. J'ai vérifié dans Fiddler qu'il n'y a pas de réponse HTTP du tout. Pour être clair, si je comprends bien une méthode de contrôleur ne devrait pas simplement se bloquer, il n'y a pas d'exception. J'ai vérifié le manque de réponse dans Fiddler. La méthode renvoie un objet valide, vérifié en passant le code dans l'instruction return finale.

Ceci est différent de la question d'origine en ce que la méthode du contrôleur est atteinte, et n'était pas avant. La raison de ceci est expliquée dans la question originale. ASP.NET Web Api. Controller not hit. No response at all. Approaches to diagnose?

MISE À JOUR

Je vois maintenant le comportement this, même si la demande complète le gestionnaire et retourne 200

ExtensionlessUrlHandler and "Recursion too deep; the stack overflowed"

1506. -GENERAL_REQUEST_END 


BytesSent 
6069 

BytesReceived 
436 

HttpStatus 
200 

HttpSubStatus 
0 

Près de la fin

ErrorDescription 
Internal Server Error 


0 ms 

Warning 
1170. -MODULE_SET_RESPONSE_ERROR_STATUS 


ModuleName 
ManagedPipelineHandler 

Notification 
EXECUTE_REQUEST_HANDLER 

HttpStatus 
500 

HttpReason 
Internal Server Error 

HttpSubStatus 
0 

ErrorCode 
Recursion too deep; the stack overflowed. 
(0x800703e9) 

Answer 1

Cela s'est avéré être une instance écrasée de RabbitMQ en combinaison avec le middleware OWin qui essayait d'utiliser cette instance (pour enregistrer des exceptions telles que l'impossibilité de se connecter à l'instance MQ; ou plutôt en essayant de les enregistrer en les envoyant à l'instance MQ) et avalait ainsi des exceptions de manière récursive. Le débordement de la pile a été causé par la réintégration sans fin de ces instances de middleware. Le middleware de journalisation émettait des exceptions car il ne pouvait pas se connecter et le middleware de gestion des exceptions traitait ces exceptions en les envoyant au middleware de journalisation. Des trucs intéressants. En plus de redémarrer pour guérir le crash et inaccessible RabbitMQ (redémarrage du service ne suffisait pas) le problème n'était toujours pas résolu (différents symptômes comme décrit ci-dessus) sauf si le paquet nuget MassTransit.RabbitMQ 3.3.2 (ancien version) et les dépendances (y compris RabbitMQ.Client) que cette version exacte apporte avec, ont été installés, plutôt que les dernières versions.

J'espère que cela aidera quelqu'un.