Persistent subscription says "lastProcessedEventNumber": 411 and "lastKnownEventNumber": 415. How to get the remaining 4 messages?

EventStoreDB
1

I have a persistent subscription and this is returned by the system:

{
  "links": [
    {
      "href": "http://localhost:2113/subscriptions/ApartmentDetailsProcessedEvents/ApartmentDetailsProcessedSubscription/info",
      "rel": "detail"
    },
    {
      "href": "http://localhost:2113/subscriptions/ApartmentDetailsProcessedEvents/ApartmentDetailsProcessedSubscription/replayParked",
      "rel": "replayParked"
    }
  ],
  "config": {
    "resolveLinktos": true,
    "startFrom": 0,
    "messageTimeoutMilliseconds": 30000,
    "extraStatistics": false,
    "maxRetryCount": 10,
    "liveBufferSize": 500,
    "bufferSize": 500,
    "readBatchSize": 20,
    "preferRoundRobin": true,
    "checkPointAfterMilliseconds": 3000,
    "minCheckPointCount": 10,
    "maxCheckPointCount": 1000,
    "maxSubscriberCount": 10,
    "namedConsumerStrategy": "RoundRobin"
  },
  "eventStreamId": "ApartmentDetailsProcessedEvents",
  "groupName": "ApartmentDetailsProcessedSubscription",
  "status": "Live",
  "averageItemsPerSecond": 0.0,
  "parkedMessageUri": "http://localhost:2113/streams/%24persistentsubscription-ApartmentDetailsProcessedEvents::ApartmentDetailsProcessedSubscription-parked",
  "getMessagesUri": "http://localhost:2113/subscriptions/ApartmentDetailsProcessedEvents/ApartmentDetailsProcessedSubscription/1",
  "totalItemsProcessed": 416,
  "countSinceLastMeasurement": 0,
  "lastProcessedEventNumber": 411,
  "lastKnownEventNumber": 415,
  "readBufferCount": 0,
  "liveBufferCount": 416,
  "retryBufferCount": 0,
  "totalInFlightMessages": 0,
  "connections": []
}

``

So I have 416 events, lastProcessed is event 411 and last known event is 415. If I start my consumer then I get this information:

[2018-08-10 07:54:04] event-store-client.debug: Subscription 84c553d39373419096cc9dfe88a86a59 to ApartmentDetailsProcessedEvents: subscribed at CommitPosition: 253677699, EventNumber: 415

``

So where did the remaining 4 events go?

I first thought that they were parked so I pressed the replay parked messages button. But pressing this doesn’t seem to do anything.

I guess that I’m not understanding properly how this works… but would like to understand the numbers and what the red icon means in the interface.

2

The lastProcessedEventNumber uses the event number in the checkpoint. You will notice that your checkpoint config has a minCheckPointCount of 10. This means a checkpoint will not be written unless there are at least 10 events since the last checkpoint.
To the best of my understanding, the other checkpoint config items can be explained as follows:

    "checkPointAfterMilliseconds": 3000, // Checkpoint after 3000 msec of no more events being handled
    "minCheckPointCount": 10, // Once 3000msec has elapsed, only checkpoint if at least 10 events have been handled
    "maxCheckPointCount": 1000, // Even if the 3000msec has not elapsed, force a checkpoint Busy systems would frequently not have gaps of no activity, so this ensures a checkpoint at least ever 1000 events.

Based on that, you can assume that the last 4 events were handled.

In my development environment I like to set the minCheckPointCount = 1. This allows me to refer to the lastProcessedEventNumber, and, if it’s been checkPointAfterMilliseconds since the last event was processed, I will see the last processed event, as it will checkpoint after each event, assuming no events where handled for the last checkPointAfterMilliseconds (3000 msec in this case).

3

Thanks that explains it. I’ll play around with the checkpoint values to see how this works :slight_smile: