Replaying parked messages priority

EventStoreDB
#1

I’m in a situation where there are a lot of parked messages those need to be replayed while new messages are coming in. So:

  1. Is there any option that we can process the parked messages and current messages at the same time ? Or can we limit the number of instances that is dedicated for replaying messages only ?

  2. If a message is acked after it is parked, would it be removed from the parked stream ?

Thanks.

#2

OK so parked messages don’t just flood… If you have live messages going at the same time they should intermingle.

I have done testing on this way back when I was implementing it (years ago), but just looking through the code it should work :smiley:

As you can see here:

https://github.com/EventStore/EventStore/blob/master/src/EventStore.Core/Services/PersistentSubscription/PersistentSubscription.cs#L401

The replay of parked is handled through an async loop. The subscription should still be receiving live events.

Now for “acked from the parked stream” what happens is that the stream is $tb’ed for the parked stream via writing metadata with $tb set on it. This code can be seen here: https://github.com/EventStore/EventStore/blob/master/src/EventStore.Core/Services/PersistentSubscription/PersistentSubscriptionMessageParker.cs#L21


Virus-free. www.avast.com

#3

Thanks Greg,
The “acked from the parked stream”: The case is when the message processing is timed out, it’s moved to the parked stream, and the message is acked after that moment. I noticed in my system the message will still be in the parked stream and be replayed later (when replaying parked messages is requested). Could we avoid that ?

Thieu.

#4

Well yeah it timed out.

There is no way to undo that timeout since its in a stream.

What you would generally do is support idempotency as this is needed for many other things as well


Virus-free. www.avast.com

#5

Thanks Greg. We do support idempotency in our system, just wanted to know if the behavior is by design.

Thieu.