TechEd: CTS405 Connected Systems: Choosing a Hosting Model - Dealing with Threads, AppDomains, and Processes
Lance Olson presented this session with a pleasant mix of analogies and deep technical stuff. The slides are also a great source of his hints and tips.
Things (managed code or killer whales - an analogy) run in an app domain, some things can have multiple app domains. Lance made an analogy of living in a plane compared with living in a hotel room, or an apartment. The MSCOREE is the butler for the app domain hotel. _CorExeMain is called when a process starts that has managed code. You can only run one CLR version per process, because the butler has to go in and like spray perfume into the hotel room first and set it all up, having two CLR versions would be like having Madonna and Whitney Housten share a hotel room.
Lance ran through the basic app domain life cycle for managed code.
Hosting environments have some things the same and some things different. Like choosing a restaurant to host you for the evening <grin>.
Manual process creation 1) Managed console executable, and 2) managed windows forms app.
The manual ones are straight forward (like fast food) and the automatic process creation ones are not (like restaurants).
Automatic Process Creation 1) Managed win NT service, 2) Enterprise services, and 3) IIS/ASP.NET
Console: default app domain, simple and no surprises, caution that there are differences in this and other hosting environments. Often developers create and test code in this environment and try to deploy to IIS/ASP.NET or Enterprise Services. Things can operate differently, such as threading models are different (free threaded in console).
Windows Forms: All in one process and default app domain the same as the console. Be aware of the UI thread - use control.BeginInvoke to marshal from IO threads to the main UI thread. Management and deployment significantly improved by Click Once.
Lance uses blue on grey for his command line windows. Lance is showing us a really simple managed application, two lines of code.
dumpbin /imports text.exe
We saw the import _CorExeMain. He changed it to a DLL and we saw _CorDllmain as the import instead.
He then ran the first app and used tlist to show his processes, proc id 3872. Then he ran enumappdomains.exe 3872 (I think this was an app he wrote himself) to list the appdomains in the app. There was only 1. He showed us this for a win forms app also.
Now automatic process creation which is the meat of this talk and a comparison of the three optoins from different viewpoints.
Starting the Enterprise Services application. Comes in through DCOM/RPC, that starts the DLLHOST.EXE process which makes the call to MSCoreEE and the process runs inside of that AppDomain. You can also set this up to run this in-process.
Starting an IIS6/ASP.NET app only happens when a request comes in. On demand startup. Reqeust comes in through HTTP.SYS and gets queued in this. A control request gets sent to the WAS (W3SVC) which spins up a worker process if there's not one already running. The worker process (W3WP.exe) contains the appdomain and it fetches the request from the queue. After this is setup all future domains go straight from the HHTP.SYS to the W3WP process and the appdomain. There's one appdomain per application.
NT Services only have automatic startup so you can't start based on a request. Lance talked about how NT Services start up, which is the same as it was in NT 4.0. IE Service dependencies, manual, auto, disabled, etc. You can have multiple managed services per process but if you do that they will all execute in the default app domain.
Process Identity - All of these hosting environments allow setting a specific identity to runas. They also allow running as the interactive user but this is not desired except for debugging the service. ASP.NET and enterprise services also support caller impersonation.
Process Pooling is available for both ASP.NET and Enterprise Services. For enterprise services CoCreateIsntance picks a process and sticks until the client calls release. For ASP.NET the first request gets set based on round robin and sticks based on the connection. The call this a web garden in ASP.NET how the round robin is selected.
Can also pool appdomains. In ES there is one appdomain per COM+ application and one COM+ application pre process - no pooling. ASP.NET allows one appdomain per IIS application but many IIS applications per process. NT Service just has the default appdomain.
Pooling thread. Enterprise services lets the thread pool grow large and requires all threads to complete - sues OS completion port thread pool which is limited only by thread contention or thread switch churn. ASP.NET will kill long running threads to let others get a chance - default is 20 worker threads.
Request Queueing. STA components cause problems, otherwise all requests get serviced. For ASP.NET it wants to satisfy the majority of requests as quickly as possible. Once the queue fills up ASP.NET rejects further requests. Again NT Services don't give you any of this...
Tip. Trying to do long lived operations inside of an ASP.NET app. This should be done by taking the long running work item and storing it to a queue, something else such as an Enterprise Service or an NT Service should be processing work items from your queue.
There's management and monitoring and there's debugging. Enterprise services have memory dumpm. ASP.NET have an orphan mode where process aren't recycled, instead you can debug an orphaned process.
Applications apparently build up cruft not unlike fish that are fed to killer whales in a tank but that spill out and dirty the tank. So you want to recycle the process.
Looking at the IIS 6 Res Kit Metabase explorer now and the thing that defines an aSP.NET application is the AppRoot key. Lance also used TLIST to get the procid for ASP.NET WP and he showed us that the ASP.NET application has two appdomains. There's the default oen that the butler created and there's a second one. He ran another ASP.NET application and showed that now there were 3 appdomains in the asp.net worker process.
.NET Remoting can be in your process, an NT services or in IIS.
WSE 2.0 adds a TCP protocol and can be hosted in your process also. Common issue is people using multiple models - ASP.NET and Enterprise Services. We are headed to a model where short lived and long lived methods can execute in harmony.
IIS7 hosting ASP.NET will have more componentization. The talk is getting a lot faster and harder to keep up. Hosting with indigo will also allow for TCP connectivity and IPC connectivity so you can disable HTTP on the box if you like.
Recommendation: build services with ASMX, use enterprise services when you need them and use .NET remoting for local machine calls. Heck we're skipping through all the best slides fast at the end here. Best get the slides for this for all the recommendations at the end of the talk.
About half a dozen people had cellphones go off in this session. How rude.