Guidance: competing consumers in windows services

EventStoreDB
1

Read http://docs.geteventstore.com/introduction/competing-consumers/ yesterday and wrote some exploratory code using ConnectToPersistentSubscription API. Wondering if there is any guidance or best practices around connecting clients from a windows service.

For example, I noticed that persistent subscriptions can be dropped for a few different reasons. If I start up a windows service that creates 3 subscriptions, then use the UI to edit the Message Timeout for the subscription, all 3 of those subscriptions get dropped and stop receiving messages. Subscriptions also get dropped when they timeout processing a message, and when the eventstore clusternode process is exited. There are other reasons too, these are just the ones I am familiar with after a day.

In a windows service, I would want to connect up new subscription clients under certain circumstances when existing subscriptions get dropped. Has anybody done this before, any experiences or knowledge to share?

Thanks,

Dan

2

" Subscriptions also get dropped when they timeout processing a message"

Please provide a test case. The message will be retried, the
subscription is not lost.

3

If I connect to a subscription like so:

public void Connect() {

_subscription = _eventStoreConnection.ConnectToPersistentSubscription(“et-MyEventType”, “testGroup”, EventAppeared, SubscriptionDropped, null, 5, false);

}

Then when new MyEventType events are added to streams, the following method gets invoked:

private void EventAppeared(EventStorePersistentSubscriptionBase eventStoreSubscription, ResolvedEvent resolvedEvent) {

Console.WriteLine($“Subscription has processed event {resolvedEvent.OriginalEventNumber}”);

eventStoreSubscription.Acknowledge(resolvedEvent);

}

However if I go to the UI and change a parameter of the subscription, for example to increase or decrease the Message Timeout, as soon as I hit save, the following method gets invoked with reason “UserInitiated” and null exception:

private void SubscriptionDropped(EventStoreSubscriptionBase eventStoreSubscription, SubscriptionDropReason subscriptionDropReason, Exception exception) {

Console.WriteLine($“Subscription has been dropped due to {subscriptionDropReason}”);

}

Afterward, as additional MyEventType events are appended to streams in the database, the EventAppeared method no longer gets invoked. I have seen this happen consistently no matter how many subscription instances are connected within the console application process. It seems that as soon as SubscriptionDropped gets invoked, the connection is essentially disposed of and no longer useful. Are you saying it should not be like this? Client API version is 3.3.1.

4

You need to explicitly handle dropped subscriptions.

private void RecoverSubscription()

{

var lastProcessedPosition = positions.GetLastProcessedPosition();

subscription = connection.SubscribeToAllFrom(

lastProcessedPosition, false,

EventAppeared,

LiveProcessingStarted,

SubscriptionDropped);

}

private void SubscriptionDropped(

EventStoreCatchUpSubscription _, SubscriptionDropReason reason, Exception exception)

{

if (reason == SubscriptionDropReason.UserInitiated)

return;

RecoverSubscription();

}

5

Yes, that’s what I was saying (though I was working with a persistent subscription, not a catch up subscription). I thought Greg was saying this should not happen, which is why I posted a test case.

6

Changing settings unsubscribes clients (the subscription is basically
reset by a user). The subscription will get dropped at clients.
Clients should re connect to subscription at this point.