Writing Highly Available Net Framework Applications by dominic.cecilia

VIEWS: 0 PAGES: 27

									    Writing Highly Available
    Future of CLR in .Net 2.0
.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
 Application Domains: Isolation & Unloading
 Host can remove code from erroneous
  process & continue execution
            Advantages

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

 Unload Application Domain without
  leaking any resources
 Customize the handling of various
  exceptional conditions
 E.g. – System.OutOfMemoryException
 Customizing Escalation Policy
    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
        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(…);
    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
          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
          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
      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
        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
     Escalation Policy - Failures
1)   Failure to allocate resource:
     •   Memory or resources managed by OS
2)   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
    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
                 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
         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
        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
        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
     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
Escalation Policy - Operations

 Specify Timeouts for operations
 Indicate actions that should occur
 Diagram – Escalation Policy of SQL
  Server 2005 Host
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
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
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
            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
             Safe Handles

 Derive from CriticalFinalizerObject
 Classes derived from SafeHandle require
  permission to call unmanaged code
 Constructor has ownsHandle parameter
 Annotate with
  SuppressUnmanagedCodeSecurityAttribute
     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
    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
        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

								
To top