PersistentSubscription with InFlight 1

EventStoreDB V21.X
#1

If you create a Persisten Subscription and set InFlight to 1 (and AutoAck to false) what are the differences (if any) between that and a catch up subscription?
In my head, both would replay in order, one at a time.

The only thing I can think of is, the consumer would be responsible for deciding what happens if an event can’t be processed (maybe it’s ok to carry on, or stop the subscription)

If there are no major differences, it would mean you could have a “catch up subscription” visible from the UI (which makes it much easier for supporting)

#2

Hi Steven,

I assume by setting InFlight to 1 you’re only using one consumer for the persistent subscription?

The difference remains the same. Persistent subscription manages the position for the client, while using catch up the client has to manage it itself. However when using a single consumer the behaviour for both the persistent subscription and catch up will be the same. That is until you restart the consumer of course.

When the event can’t be processed, the PersistentSubscription allows you to tell the server how to handle the event. Nack, Park, Retry, etc. With the catch up subscription you would indeed have to handle this yourself, as the StreamSubscription doesn’t support acknowledgement of the events.

I don’t know if I understand the part on supporting catch up subscription from the UI, but assuming you would like to use catch up for updating the UI, I would say it would be more forgivable if the UI misses an update than e.g. some service that needs to process the event.

HTH.

Cheers,

Peter

#3

Peter,

Yeah we have a single client which probably let’s us get away with this (we use catchups in other areas)
It would realyl be nice if the ES UI allowed you to view a catchup subscription (i.e. current position etc)
Having them sitting silently in the background without a visual way of knowing if they are running it’s not ideal.

#4

Hi Steven,

Given your requirement, wouldn’t it make sense to use persistent after all?

Peter

#5

For certain things, we do. The guys supporting the system need a visual to check if certain things are running. I was making sure I hadn’t missed something basic by forcing a persistent to (almost) behave the same as a catchup.

1 Like