1 / 27

Writing Highly Available .Net Framework Applications

Future of CLR in .Net 2.0. Writing Highly Available .Net Framework Applications. Sriram Ramamurthy. 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

bat
Download Presentation

Writing Highly Available .Net Framework Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related