EventStore for Orleans Grain Persistence

EventStore for Orleans Grain PersistenceIn my previous post, I used the JournaledGrain to create an Event Sourced grain.  This enabled us to raise events from within our grain which would be applied to our grain state.  Next up, which I’m covering in this post is how to use EventStore for Orleans Grain Persistence.

This means when we raise events, they will also be persisted to EventStore.  When our grain is activated, we can re-hydrate it by retrieving prior events from an EventStore stream and re-running them in our Grain to get back to current state.

Blog Post Series:


If you are unfamiliar with EventStore:

The open-source, functional database with Complex Event Processing in JavaScript.

If you don’t have a running instance, the easiest way is probably with Docker.  Pull down the latest image from docker hub and  as single node running.

docker pull eventstore/eventstore

docker run –name eventstore-node -it -p 2113:2113 -p 1113:1113 eventstore/eventstore

There is a .NETStandard 2.0 compatible client package that I will be using in our Grain Project.

Install-Package EventStore.ClientAPI.NetCore

Writing to EventStore

Anytime our grain was calling the JournaledGrain.RaiseEvent, we want to actually persist that to an EventStore Stream.  For my demo, we will have one EventStore stream per instance of an Orleans grain.  Meaning each bank account will have one event stream.

I’m going to create a new RaiseEvent method that will call the base.RaiseEvent and once confirmed they were applied, append them to our EventStore Stream.  The additional private static methods are really just helpers for (de)serializing our events from/to json.


When our Grain activates with OnActivateAsync, this is when we will fetch all the events from our event stream and apply them to our grain.  Basically this will be replaying all the events to build our grain state back up to current state.



If you want to try the demo, all the source is available on my PracticalOrleans GitHub Repo.

Do you have any questions or comments? Are you using Orleans or EventStore?  I’d love to hear about it in the comments or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Practical Microsoft Orleans

I’ve been wanting to take a deeper dive into Microsoft Orleans for awhile now.  With the next release targeting .NET Standard 2.0, it felt like an great time to do it.  This is the first blog post in a series that will go beyond a simple Hello World.  The plan is to make this a practical Microsoft Orleans guide to follow along with.

Blog Post Series:

Microsoft Orleans

If you aren’t familiar with Orleans, here’s a brief overview.

Orleans is a framework that provides a straightforward approach to building distributed high-scale computing applications, without the need to learn and apply complex concurrency or other scaling patterns.

Or maybe you have heard Orleans is an Actor model framework.  Well…

Implementation of Orleans is based on the Actor Model that’s been around since 1970s. However, unlike actors in more traditional actor systems such as Erlang or Akka, Orleans Grains are virtual actors. The biggest difference is that physical instantiations of grains are completely abstracted away and are automatically managed by the Orleans runtime. The Virtual Actor Model is much more suitable for high-scale dynamic workloads like cloud services and is the major innovation of Orleans. You can read more details in the Technical Report on Orleans.


I have to give it to the Orleans team.  Their docs seem fantastic.  I’ve read over most of their Step-by-Step guide and feel like there’s a lot of insight being shared.  There’s a section about Concurrency that has some great code samples that gives with code samples a deadlock scenario.  I found reading over these docs to be really helpful in understanding and just looking at small code samples.

Event Sourcing

One aspect that I find interesting is having a grain manage it’s state being event sourced.

Event sourcing provides a flexible way to manage and persist grain state. An event-sourced grain has many potential advantages over a standard grain. For one, it can be used with many different storage provider configurations, and supports geo-replication across multiple clusters. Moreover, it cleanly separates the grain class from definitions of the grain state (represented by a grain state object) and grain updates (represented by event objects).

My plan is to use event sourcing as grain state and persist events to Event Store.  Luckily I’m familiar enough with Event Store however have to do more reading on if there is an existing implementation or have to roll my own.

Sample Application

As with other blog series I’ve done in the past, I find it helpful to take an existing OSS application that I can fork and use as a base.

Do you have a suggestion about an application I can fork to use as a base?  I’d love to hear your suggestions.  Let me know Twitter or in the comments.

Event Store Persistent Subscriptions Demo

Event Store Persistent SubscriptionsIn my previous blog post, I talked about Catch-Up Subscriptions in-comparison to Persistent Subscriptions in Event Store.

I’ve been meaning to create a little demo as I didn’t find very much in my limited searching.

Specifically, I wanted to create a console app that would contain the subscription client  and another console app (event writer) that would write events to a stream.

This way you could run the subscription client multiple times, then run the event writer and see how the events are only received from one subscription client.


All the source code for this demo is available on GitHub.  Please take a look to follow along as the rest of this post is describing how it works.

Although I’ve added this to as a new repo on GitHub, It is also available in the EventStore.Samples.DotNet repo on GitHub along with other subscription model examples.


If you don’t have it already, download a copy of Event Store and run EventStore.ClusterNode.exe with default arguments.

This will start the Event Store server under port 1113.  The web UI will be accessible via http://localhost:2113

Create Subscription

First you need to create a subscription to a stream.  You will also provide a group name which you will also use when connecting to the subscription.

In my demo I’ve included code to create the subscription.  This is simply because I don’t want anyone running the demo to have to create it manually. The documentation discourages it from being created in your general application code.

Normally the creating of the subscription group is not done in your general executable code. Instead it is normally done as a step during an install or as an admin task when setting things up. You should assume the subscription exists in your code.

The web UI has a pretty nice interface for viewing your subscriptions as well as creating and updating them.

Event Store

Connecting to Persistent Subscription

When connecting to a persistent subscription, you must specify the stream and the group in which you use to create the subscription.

There are two other optional parameters which I’ve found to be important: bufferSize and autoAck

bufferSize: The number of in-flight messages this the server will send to the client.

autoAck: The client API will automatically acknowledge after the EventAppeared method returns.  If an exception is thrown in the EventAppeared method, the subscription will drop your subscription.

Dropped Subscription

I found it helpful to have the subscription reconnect when it is dropped.

Another case where the subscription can be dropped is if changes to the subscription are made from another client or the web UI.


Method is invoked once the subscription receives an event. As you can assume the ResolvedEvent contains the event and the eventStoragePersistentSubscriptionBase allows you to acknowledge or not acknowledge (fail) a ResolvedEvent or a array of ResolvedEvents.  If you have autoAck then you do not need to acknowledge.

Running Demo

To run the demo, simply build the solution to generate the exe’s.

Run multiple instances of PersistentSubscription.exe

Multiple instances will allow you to see how each will connect to the subscription and only receive one of the events that is written to the stream.


You can also now see in the Web UI that there are two connections.


Now if you run the WritingEvents.exe it will write 100 events to the stream.

The PersistentSubscription.exe will now have received the events.  But only one event will be sent to a client.  you can see that as our subscription is setup for Round Robin.



Source Codegithub-octocat

The source code for this demo is available on GitHub.