In 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
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.
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.
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.
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.
The source code for this demo is available on GitHub.