c# - AppDomains 与强大的服务器

Question

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

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

这是正确的还是我遗漏了 AppDomains 的某些内容？

谢谢，克里斯托夫

Answer 1

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

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

来自forum post on the topic :

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.

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.

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.

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.