-
Notifications
You must be signed in to change notification settings - Fork 10
Installing and Configuring
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
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.
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
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.
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.
Mjolnir has an implementation of IMetricEvent
built in with Hudl.Mjolnir.Events.GaugeLogMetrics
which gives you the ability to use logs for metrics.
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 Use • Commands »