Skip to content

Installing and Configuring

Chris Lewis edited this page Oct 25, 2017 · 26 revisions

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

NOTE: Mjolnir v3.0.0 targets netstandard1.6, meaning it can be used in a .NET Core application at v1.0.0 or above. It can also be used with the .NET framework v4.6.1 and above - see MS docs on .NET Standard. If your application is not compatible with .NET Standard v1.6 or above then consider using Mjolnir v2.6

Initializing the Default CommandInvoker

The entrypoint to Mjolnir is through the ICommandInvoker interface - it's what executes Mjolnir commands! The library has a default implementation, CommandInvoker, which we recommend instantiating as a singleton for your application.

Configuring the CommandInvoker - MjolnirConfiguration

The CommandInvoker expects an instance of the MjolnirConfiguration class to be provided to it's constructor. Values in this class configure behavior of the library. See Configuration for more information on configuring timeouts, bulkhead and breaker behavior.

It's perfectly fine to create an instance of MjolnirConfiguration and hardcode the config in your application or to simply use the default constructor for MjolnirConfiguration - and hence our defaults. However it's more common to read configuration from a file such that changes are much easier to make.

We have provided a sample implementation of a configuration provider which will read configuration from a JSON file and will reload values when there have been any changes to that file. See ExampleJsonConfigProvider.

A sample JSON file can be found here

Getting logs from the CommandInvoker - IMjolnirLogFactory

The CommandInvoker also expects a log factory to be passed into it's constructor. This allows you to hook up your own log provider to get Mjolnir logs into your applications. The associated interfaces should be fairly easy to implement and we have provided a default (no-op) logging implemetation within the Mjolnir library, mostly as an example, but they could be used if you don't require logs from the Mjolnir library.

Hooking into Metric Events - IMetricEvents

Though not a required parameter to the CommandInvoker constructor, you can also inject a metrics implementation to capture events of importance from the library. We use Riemann, but other clients (e.g. statsd) should work well, also. The following events are fired:

  • CommandInvoked
  • EnterBulkhead
  • LeaveBulkhead
  • RejectedByBulkhead
  • BulkheadGauge
  • BreakerTripped
  • BreakerFixed
  • RejectedByBreaker
  • BreakerSuccessCount
  • BreakerFailureCount
  • BreakerGauge

More details are available in the doc comments for IMetricEvents.

You'll need to implement Hudl.Mjolnir.External.IMetricEvents and pass it into CommandInvoker creation.

Ignoring certain exception types - IBreakerExceptionHandler

Exceptions from executed commands will cause Mjolnir to mark the command as a failure and this failure will contribute to tripping the circuit breaker for that command. You can supply an implementation of IBreakerExceptionHandler to the CommandInvoker which will allow you to ignore certain exception types. A default implementation exists in the library - IgnoredExceptionHandler.

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

IMetricEvents metricEvents = new MyImplementationOfMetricEvents(/* ... */);
//...

var commandInvoker = new CommandInvoker(
            mjolnirConfiguration,
            logFactory,
            metricEvents,
            breakerExceptionHandler)

As previously mentioned we recommend using only one command invoker per application, since the invoker holds a lot of the library's important state. Dependency Injection is a good way to achive this.


« When to UseCommands »