Writing Highly Available .Net Framework Applications

1. 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