Trying to understand the Current vs Known message

[Cleber_Junior]

Hi, I’m using the JVM client, and I’ve created a index with a Projection, then I create a Persistent Subscription and subscribe to this index.

If I start one subscriber then the messages are counted OK, if I turn it Down, then send more messages, turn it up it, it catches up with the messages, but the Current counter does not increment, so, to be sure I started another subscriber and in fact it did not receive those messages not counted…So I don’t realize what is the meaning of these counters.

If I had two subscriber for the same subscription in round robin, as soon as messages start been dispatched, the divergence between Known and Current begins! really don’t understand what is actually happening

[Olivier_Vallee]

Hi,

I have the same issue .Net client.

Is there any explanation about this ?

Cordialement,

Olivier

[Greg_Young1]

Can you give a bit more context about your problem? The original issue is rather vague.

[Olivier_Vallee]

Sure, I got a persistent subscription over a system projection ($et-).

My consumer get well the events from the subscription, and manually acknowledge them.

subscription.Acknowledge(resolvedEvent.OriginalEvent.EventId);

``

If I start/stop my consumer it get only newly post events.

But in ES UI, Current value is not updated, and the gap between Known and Current is growing.

Status is red with the number of message in the gap.

It can be refreshed when restarting the subscription(I do an update on it) .

Then If I start the consumer I will get the previous number of message that were in the previous gap starting from the end pf the stream(even though they were already acknowledge)

I try the subscription.Stop(timeout) on SubscriptionDropped as I saw in other post.

subscription.Stop(TimeSpan.FromSeconds(5));

``

I limit to only one subscriber with a Dispatch to Single strategy.

It’s my first persistent subscription:)

I’m not sure my understanding is good and what I’m missing,

Thanks for your time.

[Greg_Young1]

Do you see the same calling Acknowledge(ResolvedEvent) as opposed to picking the id yourself?

https://github.com/EventStore/EventStore/blob/master/src/EventStore.ClientAPI/EventStorePersistentSubscriptionBase.cs#L97

Just making sure the right ID is being Acked… since you have a linked event here. Also can you provide your code?

[Karolis_Lab]

What if you add more events, lets say 10 new events? Do you get the checkpoint moved?
We had similar problem where with a small event count, we would get some of the events not ACKed. There is a setting “Min Checkpoint Count” which regulates the minimum number of ACKs there should be so ES would persist to disk. It has a default value of 10, which is set in your settings. If you updated it to be 1, every ACK would be persisted, but it would sacrifice some performance. Keep in mind that you would probably need to have an idempotent consumer anyway (because of retries and such) so getting the same events after consumer restart wouldn’t be a huge problem. On the other hand, if you don’t expect a lot of traffic, it might be ok to have this setting set to 1.

• Karolis

[Olivier_Vallee]

@Greg : I first tryed with resolvedEvent.Event.EventId and see this one doesn’t aknowledge the proper event, using resolvedEvent.OriginalEvent.EventId the notification works.

@Karolis : you are right, the number of messages indicate the number of messages after the last checkpoint. And current in the ES UI is updated after the checkpoint.

Can you explain me what the max checkpoint count is?

Thanks a lot

[Olivier_Vallee]

I switch my code to
subscription.Acknowledge(resolvedEvent);

It’s much easier.