.NET Remoting 服务器端挂起
我们有一个位于 Web 应用程序和数据库之间的 .net 远程处理应用程序。 有时我们会遇到奇怪的问题。 远程调用只是挂起并且永远不会返回。 我们使用包嗅探器来检查流量。 看来是服务器端的问题。 如果我们停止服务器应用程序，将立即引发网络异常。 然而，当我们调试服务器代码时，它没有命中任何代码。 看来该请求被远程处理堆栈内的某个地方阻止了。 有人有类似的经历吗？
We have a .net remoting application sitting in between web app and database. Occasionally we get strange problem. The remote call simply hangs and never returns. We used package sniffer to check the traffic. It seems to be the server side problem. If we stop the server app, a network exception will be thrown immediately. However when we debug the server code, it does not hit any code. It seems the request is blocked somewhere inside the remoting stacks. Does anyone have similar experience?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不久前，我在使用 IPC 的 .Net 远程处理中确实遇到了类似的问题。 我不记得所有细节，所以请原谅我。 我发现的问题是我的客户端应用程序正在对服务器应用程序进行远程调用，这需要很长时间（几分钟）才能完成。 将客户端和服务器连接到调试器并捕获所有抛出的异常后，我发现远程调用实际上最终抛出了某种超时异常（我的记忆想说内部消息与 COM 相关），因为没有在超时期间，IPC 通道上正在发生活动。 显然，当这些远程连接超时时，双方的链接本质上是行不通的。 奇怪的是，我只能通过调试器看到这个异常 - 在发布模式下，我的应用程序就像你的应用程序一样挂起，没有任何迹象表明原因。 我找到了远程处理超时设置，然后简单地关闭了超时（或者将其设置得大得离谱，我再次记不清了），这解决了问题。
I did experience a similar issue in .Net remoting quite awhile ago, using IPC. I do not remember all the specifics, so forgive me. The problem that I discovered was that my client application was making a remote call to the server application which took a long time (minutes) to complete. After hooking both the client and the server up to the debugger, and catching all thrown exceptions, I discovered that the remote call actually ended up throwing a timeout exception of sorts (my memory wants to say the internal message was COM-related) since no activity was occurring over the IPC channel for the timeout period. Apparently when these remoting connections time out, the links on both sides are essentially dead-men-walking. Strangely, I was only ever able to see this exception through the debugger - in release mode, my application just hung like yours, without any indication as to why. I found the remoting Timeout settings, and simply turned off the Timeout (or made it ridiculously large, again I don't remember exactly), which fixed the problem.
事实证明，我们使用的 CMS 系统也使用 .NET Remoting，并且它覆盖了我们的安全设置。 我们关闭了远程应用程序上的安全设置，现在一切正常。
It turns out to be the CMS system we are using also uses .NET Remoting and it overwrites our security settings. We turned off the security settings on our remote app and everything works okay now.