C# – AppDomains vs. a robust server

appdomainc

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.

Is that correct or am I missing something with AppDomains?

thanks,
Christoph

Best Answer

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.

From a 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.

Related Solutions

.net – Good example of use of AppDomain

Probably the most common one is to load assemblies that contain plug-in code from untrusted parties. The code runs in its own AppDomain, isolating the application.

Also, it's not possible to unload a particular assembly, but you can unload AppDomains.

For the full rundown, Chris Brumme had a massive blog entry on this:

~~http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx~~

https://devblogs.microsoft.com/cbrumme/appdomains-application-domains/

C# – Cross-thread operation not valid: Control accessed from a thread other than the thread it was created on

As per Prerak K's update comment (since deleted):

I guess I have not presented the question properly.

Situation is this: I want to load data into a global variable based on the value of a control. I don't want to change the value of a control from the child thread. I'm not going to do it ever from a child thread.

So only accessing the value so that corresponding data can be fetched from the database.

The solution you want then should look like:

UserContrl1_LOadDataMethod()
{
    string name = "";
    if(textbox1.InvokeRequired)
    {
        textbox1.Invoke(new MethodInvoker(delegate { name = textbox1.text; }));
    }
    if(name == "MyName")
    {
        // do whatever
    }
}

Do your serious processing in the separate thread before you attempt to switch back to the control's thread. For example:

UserContrl1_LOadDataMethod()
{
    if(textbox1.text=="MyName") //<<======Now it wont give exception**
    {
        //Load data correspondin to "MyName"
        //Populate a globale variable List<string> which will be
        //bound to grid at some later stage
        if(InvokeRequired)
        {
            // after we've done all the processing, 
            this.Invoke(new MethodInvoker(delegate {
                // load the control with the appropriate data
            }));
            return;
        }
    }
}

Best Answer

Related Solutions

.net – Good example of use of AppDomain

C# – Cross-thread operation not valid: Control accessed from a thread other than the thread it was created on

Related Topic