Web API控制器方法执行到结束.没有HTTP响应.挂起 [英] Web API Controller method executes to end. No HTTP response. Hangs

问题描述

我正在寻找一种调试这种情况的方法.我已经在Fiddler中验证，根本没有HTTP响应.需要明确的是，据我了解，控制器方法不应简单地挂起，也不例外.我已经证实Fiddler缺乏回应.该方法返回有效的对象，并通过逐步执行代码直至最终的return语句进行验证.

I am looking for an approach to debugging this scenario. I have verified in Fiddler that there is no HTTP response at all. To be clear, as I understand it a controller method should not simply hang, there is no exception. I have verified the lack of response in Fiddler. The method returns a valid object, verified by stepping through the code to the final return statement.

这与原始问题的不同之处在于，命中了控制器方法，而不是以前的方法.最初的问题解释了这样做的原因. ASP.NET Web Api.控制器未命中.完全没有回应.诊断方法?

This is different from the original question in that the controller method is hit, and was not before. The reason for this is explained in the original question. ASP.NET Web Api. Controller not hit. No response at all. Approaches to diagnose?

更新

我现在看到此行为，即使该请求完成处理程序并返回200

I am now seeing this behaviour, even though the request completes the handler and returns 200

ExtensionlessUrlHandler和递归太深；堆栈溢出""

1506.  -GENERAL_REQUEST_END 


BytesSent
6069 

BytesReceived
436 

HttpStatus
200 

HttpSubStatus
0 

从尽头开始

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) 

推荐答案

原来是RabbitMQ崩溃的实例，并与尝试使用该实例的OWin中间件结合使用(以记录无法连接到的异常) MQ实例；或者尝试通过将它们发送到MQ实例来尝试记录它们)，因此以递归方式吞噬了异常.堆栈溢出是由于不断地重新进入这些中间件实例而引起的.日志记录中间件引发异常是因为它无法记录日志，并且异常处理中间件通过将其发送到日志记录中间件来处理这些异常.有趣的东西.

This turned out to be a crashed instance of RabbitMQ in combination with OWin middleware that was trying to use that instance (to log exceptions such as being unable to connect to the MQ instance; or rather attempting to log them by sending them to.. the MQ instance) and was thus swallowing exceptions in a recursive fashion. The stack overflow was caused by re-entering these middleware instances endlessly. The logging middleware was throwing exceptions because it could not log and the exception handling middleware was handling those exceptions by sending them to the logging middleware. Interesting stuff.

除了重新启动以解决崩溃且无法访问的RabbitMQ(重新启动服务还不够)之外，问题仍然没有得到解决(如上所述的不同症状)，除非使用nuget软件包MassTransit.RabbitMQ 3.3.2(旧版本) )以及此确切版本附带的依赖项(包括RabbitMQ.Client)已安装，而不是最新版本.

In addition to re-booting to cure the crashed and inaccessible RabbitMQ (restarting the service was not enough) the problem was still not resolved (different symptoms as described above) unless the nuget package MassTransit.RabbitMQ 3.3.2 (old version) and the dependencies (including RabbitMQ.Client) which this exact version brings with it, were installed, rather than the latest versions.

我希望这会对某人有所帮助.

I hope this will help someone.

这篇关于Web API控制器方法执行到结束.没有HTTP响应.挂起的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！