Persistent subscribtion supervisor feature

EventStoreDB
#1

There is a situation when a system must have less active subscribers then there are nodes.

For example we have three nodes and only one active subscriber can handle stream events. I mean to handle not just a one event at a time but all events from a stream by one subscriber. If the node with this active subscriber goes down, the next should take over and create a subscription on another node. So the system has one active subscriber and two “standby” subscribers.

EventStore has persistent subscriptions now, and it knows how many subscribers are there connected. When there are none, EventStore could ask any “standby subscriber” to connect to this “orphaned” subscription. So EventStore could act as a supervisor here, and keep subscribers alive in general.

There is a way to implement this functionality now using custom “standby stream”, with custom Supervisors sitting on every node and polling EventStore Rest API, but wouldn’t it be great to have this functionality out of the box?

Just interesting if this is only me who has this problem :slight_smile:

#2

Have you seen prefer single vs round robin on subacription group?

With prefer single and two subscribers it will send all messages to the first subscriber unless its gone or cant keep up.

#3

No, if I would the question would sound differently I guess :slight_smile: Yes, this will solve the max-one subscriber problem.

If I have 16 subscribtions, the first node subscribed to all 16, then the second, the the third. And then the new events appear on all 16. As I understand these new events will go on different nodes, not on the first that subscribed.

2015 m. sausis 16 d., penktadienis 13:38:44 UTC+2, Greg Young rašė:

#4

Thats with round robin… default

#5

So if I use PreferDispatchToSingle then I should take care of connecting in round-robin, right?

2015 m. sausis 16 d., penktadienis 14:39:17 UTC+2, Greg Young rašė:

#6

Basically it’s not a big problem if I will have some Idle timeout, and reconnect then I will change the client order…

2015 m. sausis 16 d., penktadienis 14:52:03 UTC+2, Mindaugas Pielikis rašė:

#7

If you look their are tests describing the bheaviour
https://github.com/EventStore/EventStore/blob/dev/src/EventStore.Core.Tests/Services/PersistentSubscription/PersistentSubscriptionTests.cs#L285

Basically it works as follows. If the first client can accept messages
it will prefer to give them to that client. If it cant it will fall
back to giving it to a client that can accept

#8

Thanks! I got it, it solves a lot of problems. No supervisor is needed. almost…

The only problem left is that the connections are not spread in round robin style. The first machine that boots takes all the load. But it happens only on the first cluster start. Then if subscriptions will reconnect on some timeouts then the connections will “move” across the cluster… These will not be beautifully aligned across the cluster, but it’s ok.

2015 m. sausis 16 d., penktadienis 16:34:32 UTC+2, Greg Young rašė:

#9

use multiple streams ...

#10

yeah, multiple is better than one.