AppDomains 与强大的服务器 [英] AppDomains vs. a robust server

问题描述

经过一些研究，似乎 AppDomains 并不是构建托管服务器的真正工具.根据我的理解，如果在创建的 AppDomain 中存在未处理的异常(如果从创建的 AppDomain 中的线程抛出异常)，托管服务器仍然会崩溃.因此，在这种情况下，如果托管服务器托管了一个泄漏异常的服务，这也会导致默认的 AppDomain 失效.

after doing some research it seems that AppDomains are not really a tool for building a hosting server. From my understanding, the hosting server will still crash if there is an unhandled exception in a created AppDomain (if the exception is thrown from a thread in the created AppDomain). So in that case if the hosting server hosts a service which leaks exceptions this will bring down the default AppDomain as well.

所以我想从服务器架构的角度来看，没有什么比创建子进程并监控它们更好的了.

So I guess from a server architecture point-of-view there is nothing better than creating child processes and monitoring them.

这是正确的还是我在 AppDomains 中遗漏了什么?

Is that correct or am I missing something with AppDomains?

谢谢，克里斯托夫

推荐答案

如果你可以控制在其他 AppDomain 中创建的线程，你也可以通过在线程 main 方法中使用 catch-all 块来处理异常.

If you can control the threads created in the other AppDomain, you can also handle exceptions by using catch-all blocks in the thread main method.

除此之外，只要您使用默认主机，我相信您的假设是正确的.但是，如果您自己托管运行时，您也可以处理未处理的异常.

Other than that, as long as you use the default host, I believe that your assumption is correct. However, if you host the runtime yourself, you can also handle unhandled exceptions.

来自 论坛发布主题:

嗯，这是可能的.你必须创建您自己的 CLR 主机.那开始使用 ICorBindToRuntimeEx().你得到完全控制 AppDomains抛出异常.它正在由 MSFT 软件使用，如 ASP.NET 和SQL Server 2005.当你写一个服务，您正在与默认 CLR 主机实现和它当任何时候终止进程引发未处理的异常，无论 AppDomain 导致了什么例外.

Well, it is possible. You'd have to create your own CLR host. That starts with ICorBindToRuntimeEx(). You get to have full control of AppDomains that throw exceptions. And it's being used by MSFT software like ASP.NET and SQL Server 2005. When you write a service, you are working with the default CLR host implementation and it terminates the process when any unhandled exception is raised, regardless of what AppDomain caused the exception.

问题是，像 ASP.NET 和 SQL 这样的主机服务器有一个非常明确的代码执行路径.在网络服务器中，托管代码因页面而运行要求.在 dbase 服务器中，它运行因为一个查询.当某事坏事发生了，他们有奢侈的简单地中止一切请求开始(杀死AppDomain) 并返回对不起，做不到"状态回到客户.你可能见过，在旧的论坛服务器崩溃网站很简单，但没有阻止它服务其他请求.实际上并不能 100% 确定这一点.

Problem is, hosts like ASP.NET and SQL server have a very well defined code execution path. In a web server, managed code runs because of a page request. In a dbase server, it runs because of a query. When something bad happens, they have the luxury of simply aborting everything that the request started (killing the AppDomain) and returning a "sorry, couldn't do it" status back to the client. You might have seen it, crashing the forums server on the old web site was pretty trivial but didn't stop it from serving other requests. Not actually 100% sure about that.

您的服务实现是可能没有那么干净.我不能告诉你，你什么都没说它.一般，有问题中止线程.你总是当有一个线程时必须中止线程未处理的异常.一项服务通常有一个线程，由OnStart() 方法.中止它杀死服务器直到有人停止并重新开始.

Your service implementation is probably not nearly as clean. I can't tell, you didn't say anything about it. It general, there's a problem with aborting a thread. You always have to abort a thread when there's an unhandled exception. A service typically has one thread, started by the OnStart() method. Aborting it kills the server until somebody stops and starts it again.

你绝对可以做得更多比那更有弹性，你可以开始一个启动子线程的主"线程响应外部事件的线程这使您的服务发挥作用.终止子线程因为未处理的异常是你可以恢复的东西从.但是，如果你接下来步骤，为什么没有子线程捕获异常并将其传递回主线程，因此它可以创建一个关于做什么的明智决定下一个.

You can definitely make it more resilient than that, you could start a "master" thread that launches child threads in response to external events that makes your service do its job. Having a child thread terminated because of an unhandled exception is something you could possibly recover from. But then, if you make that next step, why not have the child thread catch an exception and pass it back to the master thread so it can make an intelligent decision about what to do next.

默认CLR的冷酷事实主持人是:如果你不愿意处理失败，它不会为你做这项工作.它不应该，.NET 1.x 对线程的行为无一例外死亡是一个重大在 .NET 中得到纠正的错误2.0.

The cold hard fact of the default CLR host is: if you are not willing to deal with failure, it is not going to do the job for you. And it shouldn't, the .NET 1.x behavior to threads that died with exceptions was a major mistake that got corrected in .NET 2.0.

你知道该怎么做:处理失败.或者写你自己的主机.或者接受事情可能超出你的控制并记录一条好的错误消息，以便您可以告诉您的客户该怎么做.我强烈推荐后者.

You know what to do: handle failure. Or write you own host. Or accept that things could be beyond your control and log a good error message so you can tell your customer what to do. I'd strongly recommend the latter.

这篇关于AppDomains 与强大的服务器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！