1. Writing Highly Available .Net Framework Applications
Future of CLR in .Net 2.0
Writing Highly Available .Net Framework Applications
Sriram Ramamurthy

2. Introduction Customize CLR for Application Scenarios
High Degree of Availability
Process must live for a very long time
Provide features for host – handle exceptional conditions
Application Domains: Isolation & Unloading
Host can remove code from erroneous process & continue execution

3. Advantages Host runtime code – Reliable
Handle Resource Exhaustion & Exceptional Conditions
How to handle add-ins that might not be written properly?

4. Goals Unload Application Domain without leaking any resources
Customize the handling of various exceptional conditions
E.g. – System.OutOfMemoryException
Customizing Escalation Policy

5. Application Domain Isolation & Process Lifetimes
Process should not crash under exceptional conditions
Why build such a complex infrastructure?
Why not simply write managed code to handle all exceptions properly?
Writing reliable managed code handling all exceptions is impractical

6. Application Domain Isolation & Process Lifetimes
CLR Model of executing managed code
May throw exception in any line of code
Unexpected Memory and runtime operations
Memory Allocation
MSIL – to be JITed
Boxing of Value Types
E.g. HashTable.Add(“Entry1”, 5);
Using PInvoke – InPtr semHandle = CreateSemaphore(…);

7. Application Domain Isolation & Process Lifetimes
.Net Framework assemblies & eXtensible applications – if practical
What about add-ins ?
CLR 1.0, 1.1 – no guarantee for high availability
No such need due to lack of CLR hosts
Microsoft ASP.Net – Process Recycling Model

8. ASP. Net & IIS Multiple processes – load balancing incoming requests
High Demand – more processes created
Low Demand – processes idle or killed
High Scalability achieved – Process recycling model
Web applications – request or connection is stateless

9. ASP. Net & IIS Process hangs or fails
Process – kill safely without affection application state
User – Try Again Later, error message
Refresh browser and resend request to different process

10. CLR Design Decisions Works well – Web Servers
Does not work well – Database Servers
High per Process state – starting a new process becomes expensive
.Net 1.0, 1.1 – CLR Host (ASP . Net)
.Net 2.0 – CLR Host (SQL Server 2005)
Shall support long lived processes

11. Failure Escalation
.Net 1.0, 1.1 – certain unhandled exceptions will be swallowed
Does not terminate process
Silent Failures & Process Corruption
.Net 2.0 – all unhandled exceptions will bubble up affecting entire process
Make failures more apparent & easier to debug

12. Escalation Policy - Failures
Failure to allocate resource:
Memory or resources managed by OS
Failure to allocate resource in critical region of code:
Block of code shared b/w multiple threads
Code relies on state from another thread cannot be cleaned up by terminating running thread – integrity not guaranteed
E.g. SQL Server:
Abort thread - if failure to allocate resource
Unload Application Domain – if thread is in critical region

13. Escalation Policy - Failures
How does CLR know – if code is in critical region ?
CLR detects code executed – waits on a synchronization primitive (mutex, event, semaphore or locks)
Resource failure occurs in a region depending on sync primitive – code is in critical region

14. CLR Catch
CLR ability to detect code waiting on sync primitive – limited
System.Threading – mutex & events
CLR tracks locks created in managed world
Add-ins – given full trust in CAS & use PInvoke to create sync primitives by calling Win32 API’s
Unknown to CLR – outside realm of managed code
Won’t be reported as critical region code if failure occurs

15. Escalation Policy - Failures
Fatal Runtime Error:
Internal error – cannot continue to execute managed code
Exit process or disable CLR
Orphaned Lock:
Sync primitive is created but never freed
E.g. – Mutex or Monitor created on a thread that is aborted before lock is freed
Lock is Orphaned and can never be freed
Result in Resource Exhaustion

16. Escalation Policy - Actions
Throw an exception:
Default action – resource failures
E.g. – StackOverflowException, OutOfMemoryException
Gracefully Abort Thread:
Throws ThreadAbortException on terminating thread
CLR gives add-in chance to free resources by running code in finally blocks

17. Escalation Policy - Actions
Rudely Abort Thread:
No guarantee about cleaning up add-in code
Use to remove threads that do not gracefully abort
Gracefully Unload Application Domain:
Gracefully abort all threads
Free CLR data structures associated with domain
Finalizer is run for all objects in domain

18. Escalation Policy - Actions
Rudely Unload Application Domains:
Rude abort of all threads
CLR data structures are freed
No guarantee of Finalizers to run
Gracefully exit Process:
Gracefully unload application domains
Rudely exit Process:
Rudely unload application domains
TerminateProcess – Win32 API
Disable the CLR:
Prevent execution of managed code
Process is still alive – continue other work
E.g. – SQL Server Process

19. Escalation Policy - Operations
Specify Timeouts for operations
Indicate actions that should occur
Diagram – Escalation Policy of SQL Server 2005 Host

20. Critical Finalization, Safe Handles & Constrained Execution Region
Ensure application domains unload without leaking resources
Guarantee native handles held will be closed properly
Framework classes – wrappers around native handles
E.g. System.IO, System.Net
Dispose Pattern & Object Finalizers – no guarantee that they run

21. Critical Finalization, Safe Handles & Constrained Execution Region
Critical Finalizer:
CLR will always run
Guaranteed to complete
System.Runtime.ConstrainedExecution.Cri—ticalFinalizerObject
Safe Handle:
Wrapper around native handle
BCL rewritten in .Net 2.0 using Safe Handles
System.Runtime.InteropServices.SafeHandle

22. Critical Finalization, Safe Handles & Constrained Execution Region
CER:
How is it that it always run and always complete?
Block of code in which exceptions are never thrown due to lack of resources
CLR Steps:
Prepare CER
Restrict Operations inside CER

23. Guidelines for Writing Highly Available Managed Code
Use Safe Handles to Encapsulate Native Handles:
Use classes in System.Runtime.InteropServices
Write a custom class
Create a class derived from System.Runtime.InteropServices
Provide a constructor that enables callers to associate native handle
Implement ReleaseHandle method
Implement IsInvalid Property

24. Safe Handles Derive from CriticalFinalizerObject
Classes derived from SafeHandle require permission to call unmanaged code
Constructor has ownsHandle parameter
Annotate with SuppressUnmanagedCodeSecurityAttribute

25. Guidelines for Writing Highly Available Managed Code
Use only Synchronization Primitives provided by . Net
Code is shared or in Critical Region – sync primitives
System.Threading – Monitor, Mutex, ReaderWriterLock
Custom primitives – CLR cannot detect shared state, Escalation Policy cannot be used

26. Guidelines for Writing Highly Available Managed Code
Ensure calls to Unmanaged Code return to CLR:
Thread can enter a state that prevents CLR to abort it.
Use PInvoke – call unmanaged API and waits infinitely on sync primitive or blocks
CLR has no control of unmanaged code
Provide timeout values
Regain control and ask CLR to abort thread

27. Guidelines for Writing Highly Available Managed Code
Annotate Your Libraries with Host Protection Attribute:
Host Protection to prevent API’s that violate programming models
Prevent add-ins from using any API that allows it to share state across threads
Reduce resource failures and application domain unloads
Use custom attribute HostProtectionAttribute