Version 2 Installing and Configuring

IMPORTANT This is documentation for versions 2.x and earlier. For the newest version see: Installing-and-Configuring

Installation is fairly minimal - just grab Hudl.Mjolnir from nuget.org using your Package Manager GUI or Console.

Mjolnir needs you to specify a configuration provider. The ConfigurableValues within the app all have sensible defaults, but you'll want to adjust them after observing how your application behaves.

Initializing the Default File Configuration Provider

Mjolnir ships with a configuration provider implementation that can read configuration values from a file; set the provider on application startup (before you use any Commands):

using Hudl.Config;

//...

ConfigProvider.UseProvider(new FileConfigurationProvider(@"c:\path\to", "config-file.txt"));

Configuration file contents are just Key=Value pairs, e.g.:

mjolnir.foo.bar.baz=5000

See Configuration Keys for available timeout, bulkhead, breaker, and other keys.

If you don't set a configuration provider, default values (defined in the code) will be used for everything in Mjolnir (which isn't ideal, because you'll want to tune components and commands for your application).

Hooking into Metric Events

You can also inject a metrics implementation to capture events of importance. We use Riemann, but other clients (e.g. statsd) should work well, also. The following events are fired:

• CommandInvoked
• EnterBulkhead
• LeaveBulkhead
• RejectedByBulkhead
• BulkheadConfigGauge
• BreakerTripped
• BreakerFixed
• RejectedByBreaker
• BreakerSuccessCount
• BreakerFailureCount
• BreakerConfigGauge

_{More details are available in the doc comments for IMetricEvents.}

You'll need to implement Hudl.Mjolnir.External.IMetricEvents and set it on CommandContext.

using Hudl.Mjolnir;
using Hudl.Mjolnir.External;

//...

CommandContext.MetricEvents = new MyMetricsHandler();

Set CommandContext.MetricEvents early on application startup; breakers and bulkheads will cache their metrics implementations, and won't pick up a new one if you set it after they've been created.

SmartThreadPool dependency

Mjolnir uses SmartThreadPool, but has to package and reference it directly. See Issue #16.

Initializing Configuration for Unit testing

This is documentation for old version. For version 3 and newer MjolnirConfiguration is injectable.

Some parts of Mjolnir aren't (yet) easily injected - configuration is one.

Commands assume that configuration has been initialized and is available, but the out-of-the-box ConfigProvider implementation doesn't automatically get set (and is by default null).

To test code that has a Command in it, you'll need to initialize the ConfigProvider first. If you're using Moq, it might look something like this:

var mock = new Mock<IConfigProvider>();
// Optional: Mock the behavior of the provider's .Get()
// to control inaccessible configuration during tests.
ConfigProvider.UseProvider(mock.Object);

Calling UseProvider should be enough. Most config values in Mjolnir are either injectable or have a default that won't get in the way; setting the provider just gets around NullReferenceExceptions that can happen when config values are accessed within ConfigurableValue.

If you do mock the .Get() behavior with custom properties, you may want to tear that behavior down at the end of the test. Otherwise, since ConfigProvider is global, it will leak into other tests and affect their behavior.

---

« When to Use • Commands »