在 IIS 应用程序池回收期间调试应用程序行为
我有一个用 C# 编写的 Web 服务。 在池回收期间它的行为相当奇怪。
如果我配置一个包含 5 个工作进程的池，这些进程应该在 100 个请求后回收（在生产中实际上是 10000 个，但没关系）。对于每个进程的前 100 个（即 500 个请求），我得到了正确的响应，但之后某些请求返回了不正确的结果（我也得到了超时，但这没关系，因为进程正在回收）。
由于这些不正确的结果似乎是在回收后发生的，因此在服务启动时，很难仅附加调试器并查看会发生什么（因为当回收发生时调试器被分离）。
所以我的问题是：
1.有人知道调试这种事情的好方法
编辑：2.一个碰巧知道可能出问题的人（服务在请求之间没有状态信息）-我发现了错误，通过附加调试器并幸运地看到一个异常（捕获在全局异常处理程序中 - 天哪，我讨厌那些）：但是第一个问题仍然存在。有没有比附加调试器更简单的方法，希望您及时看到错误。
I have a web service written in C#.
It behaves rather strange during pool recycling.
If I configure a pool with 5 worker processes which should recycle after say 100 requests (in production its actually 10000 but nevermind that). I get the proper response for the first 100 per process (i.e 500 requests), but after that some of the requests returns an improper result (i also get timeouts but that is okay as the process is recycling).
Since these improper results seems to happen AFTER the recycle, while the service is starting up it is kinda hard to just attach the debugger and see what happens (as the debugger is dettached when the recycle occurs).
So my question(s) is/are:
1. Do anybody know a good method for debugging this kind of thing
Edit: 2. Anbody who happens to have an idea on what might be wrong (the service has no state information between requests) - I found the error, by attaching the debugger and luckily seeing an exception (caught in a global exception handler - god i hate those): But the 1 question still stands. Is there an easier way than attaching the debugger and hope you make it in time to see the error.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你应该明确什么是不正确的结果。如果这不是 .NET 错误，您应该检查您的代码并在您自己的代码上添加一些应用程序级别的日志记录。
只有当您没有其他办法可以求助时，调试器才能提供帮助。
You should make it clear what is the improper result. If it is not a .NET error, you should review your code and add some application level logging on your own code.
A debugger can only help when you have nothing else to resort to.
我最终所做的（目前）是删除大部分“半全局”try/catch/do-nothing 处理程序，然后编写一个 SoapExtension 来处理“未处理的异常”，并转储出我能找到的所有信息靠近一点。
我从 Jeff Atwood 关于 CodeProject 的文章中获得了大部分灵感：http://www.codeproject。 com/kb/aspnet/ASPNETExceptionHandling.aspx
它与附加调试器并不完全相同，但现在必须这样做。
What I have ended up doing (for now), is to remove most of those "semi-global" try/catch/do-nothing handlers and then write a SoapExtension for handling "Unhandled Exceptions", and dump out all the information I can come near.
I got most the inspiration from Jeff Atwood's article on CodeProject: http://www.codeproject.com/kb/aspnet/ASPNETExceptionHandling.aspx
Its not really the same as attaching the debugger, but will have to do for now.