Zero-Downtime Code Deployments with MEF

Adding production binaries to a .NET WebApp at runtime requires the application pool to restart. Unless you have the infrastructure to address this (ideally multiple servers and application instances setup for automatic fail-over, and a true Service Oriented Architecture with router services in front of your processing services), this means downtime for your users. For internal enterprise development, legacy applications, or proof of concept projects that outgrew their initial goals, not having the requisite infrastructure is a common scenario.

The approach described below quickly mitigates this issue by allowing your application to load some of its code-components during runtime using the Managed Extensiblity Framework. It relies on MEF for loading assemblies that share an interface at runtime, and RequestRouter object that routes the different requests to the appropriate implementation. However, it is no substitute for a more robust architecture – especially since MEF would be running these assemblies within the application domain of your main application (with access to all of its in-memory objects, and the possibility that bad component code could cause your entire application to crash).

Setting Up Extensible Components

None of this would work without using components which share an interface, for example:

Report interface for application driven reports:

interface IReportDefinition
{
    string ReportName; // unique identifier for this report definition
    ReportResponse ExecuteReport(ReportParameters paramaters);
    bool AcceptsExecutionRequest(ReportParameters parameters);
}

Integration message handler interface:

interface IMessageHandler
{
    string MessageName; // unique identifier for this type of message
    MessageResponse HandleMessage(Message msg);
    bool AcceptsExecutionRequest(ReportParameters parameters);
}

Calculation handler interface:

interface ICalculationHandler
{
    string CalculationName; // unique identifier for this type of calculation
    CalculationResult PerformCalculation(CalculationInputParameters paramaters);
    bool AcceptsExecutionRequest(CalculationInputParameters parameters);
}

In a similar manner, each interchangeable component collection can be setup as an interface. Another important detail is to keep the definition of the interface in a different assembly (ie project) than the implementations of the interface. This means the two would get compiled into different DLL’s, and different report definitions wouldn’t need to depend on each other. So far, this is all part of standard object-oriented design.

Using MEF and Handling Requests

To tie MEF into the solution, we need to setup the correct attributes on the reportdefinition implementations:

[Export(typeof(IReportDefinition)), PartCreationPolicy(CreationPolicy.NonShared)]
public class TestReportDefinition : IReportDefinition
{...}

The [Export] attribute specifies instances of this class will be exported by MEF (to be imported elsewhere). A corresponding [ImportMany] attribute with the same type in the RequestRouter class identifies the list which will contain all the instances of the different IReportDefinition object:

class RequestRouter{
   ...
   [ImportMany(typeof(IReportDefinition), AllowRecomposition = true)]
   protected IEnumerable<IReportDefinition> ReportDefinitions { get; set; }
   ReportResponse RouteReport(ReportParameters parameters)
   {
       foreach(var repDef in ReportDefinitions)
          if ((repDef.AcceptsExecutionRequest(parameters)) // find first match
              return repDef.ExecuteReport(parameters);
       throw new ReportNotFoundException(parameters); // couldn't find the report
   }
   ...}

The collection is iterated through whenever a request gets to the RouteReport method.

The magical (it uses .NET reflection) command that instantiates and loads the IReportDefinition objects into the ReportDefinitions IEnumerable is the CompositionContainer.Compose() method. This is how you can tie it to two different directories:

var catalog = new AggregateCatalog();           
catalog.Catalogs.Add(new DirectoryCatalog("C:\\ExtensionsPath1\\"));
catalog.Catalogs.Add(new DirectoryCatalog("C:\\ExtensionsPath2\\"));
var batch = new CompositionBatch();
batch.AddPart(this); //populates the collection of composable parts in this object
CompositionContainer container = new CompositionContainer(catalog); 
container.Compose(batch);

Note: the compose method can fail(if the assemblies are not loaded correctly, if the .NET versions dont match, etc.) so it would be a good idea to wrap it in a Try..Catch statement and explicitly handle reflection exceptions. 

Once we setup MEF to load assemblies from a set of folders, all we need to do is attach a FileSystemWatcher to those folders’ change and added events, and trigger the ‘Compose’ method above to update our collection of report definitions.

This method will work correctly for any new assemblies dropped in the extension paths. But it will not work for multiple instances of the same assembly unless the assembly is strongly named. The only workaround I could find is to rename the assembly before dropping it into the extensions folder (so it is treated as a new assembly) and update the RouteRequest method to pick the assembly with the latest modified date for the request.

Next Steps:

  • Put together a working example of the above in .NET Fiddle using a very small assembly (loaded from an in-line defined byte array)
  • Explore the Microsoft Addin Framework for better code isolation
  • Explore convention-based MEF (instead of using attributes)

 

3D Modeling a Marbles-Holder

In a previous post (click for code), I shared an OpenScad script that allows for the creation of arbitrary tracks.  Measuring the diameter of a marble, and using points on a helix, I created a track that functions as a marbles-holder.  This is the track printed in black using an Up Box 3d printer:

marble_holder_without_marbles

And filled with marbles:marble_holder_with_marbles

Next Steps:

  • I manually selected the set of points for this track. I would like to setup the mathematical formula for a helix in order to create a smoother layout.
  • Rendering time for the tracks script is really slow. I am looking for ways of making it more efficient.
  • Creating a full pipe (not just a track) and printing it would be nice and could open the door for printer more complex 3d objects. One of the difficulties with printing pipes not allowing the printer to produce supports (because if it does, they would be very difficult to remove).

Trying Tries (C# IDictionary Generic Trie)

4-key Trie

Tries are a classic implementation of the symbol-table (or associative array) abstraction. They allow for quick retrieval of values based on (typically string) keys and optimize lookup performance. They are a useful way of implementing a dictionary and excel for cases where you would want to find non-exact matches (ie longest prefix match), or all possible suffixes given a starting key (ie a drop-down that shows you all of the different options as you start typing in text).

There are a few good C# Trie implementations available online (see here, and here), but I did not see any that implement the C# Generic Dictionary interface. My goal was to create a Trie implementation that could be used interchangeably with the default C# dictionary, and could also be used with non-string keys.

All of the code is available here. One significant caveat – the overhead I added to make the structure work with the IDictionary interface has a performance impact. In many cases, the default Dictionary implementation outperforms this Trie implementation (more details below). However, even with a relatively inefficient implementation, the Trie outperforms the hashtable-based .NET Dictionary for the longestPrefix method.

How Do Tries Work

Trie Example - Right Oriented
Image 1: Example of a string Trie for ‘A’, ‘AD’, ‘ADD’, ‘ADDRESS’, ‘BAT’

A Trie is a type of tree where every arc represents a character and the path from the root to a value node represents a valid key.

Above is an example of a simple Trie with the nodes marked in green being accepting ‘value nodes’. The Trie data structure maintains a reference to the root node.

Finding a key means traversing down the root node character by character. If we end up with a null reference or a non-value node, the key could not be found.

The Trie structure is constructed whenever adding a key, and when a key is removed the appropriate nodes are removed from the tree (for example, removing ‘ADDRESS’ from this Trie would remove 4 nodes):

Trie Example - post removal
The Trie in Image 1 after removing the ‘ADDRESS’ key

The strength of the Trie data structure is that lookup time would be proportional to the size of the key, rather than to the number of elements in the data structure. For small keys (ie words in the English language) this is O(1) vs. O(logn) for binary search. It puts the Trie on par with a hash table for average time complexity.

Performance vs. .NET Dictionary

The .NET Dictionary implementation is an efficient hash table implementation with O(1) lookups. It has a lot less overhead than this Trie implementation, and would easily outperform it for general CRUD operations. However, for the Longest Prefix operation – the Trie wins every time. Since a scan of the entire dataset is not necessary, the Trie is over 100 times more efficient than the basic Dictionary implementation:

Trie v Dictionary Longest Prefix Performancel

However, for finding all suffixes, both exhibit O(1) and the .NET Dictionary outperforms the Trie. This is likely due to the efficient implementation of string operations in .NET:

Trie v Dictionary Find All Suffixes Performancel

Next Steps

  • This Trie implementation stores the entire string key in each node. This is very space inefficient, but was necessary to fit the Trie into the .NET dictionary interface. I would like to find a way to store each letter only once.
  • The internal tree data structure relies on a Dictionary to connect each node to its children. With more knowledge of the alphabet, this can be optimized.
  • Implementation of ternary search tries
  • Hybrid dictionary that uses both a Trie and a hashtable to optimize for all operations without sacrificing too much space.
  • Explore other, non-string use cases of Tries.
  • Since Tries are a specific type (non-cyclical, tree vs. graph) of a finite state automaton look to see if there are more general solutions that can bridge both problem sets.