Closed lukaszstolarczuk closed 2 years ago
@karczex , I browsed through the code once more, and I believe in current implementation this fix is good (but that's just one opinion 😄 ).
All I had to do was update the tests.
Yeah, I realized this is INVALID_TIMESTAMP is misleading. In this PR: #201 I just replaced it with
0
(without any constant). I think it's cleaner that way, and we don't really need anything like "invalid timestamp".Reviewable status: 0 of 4 files reviewed, 1 unresolved discussion (waiting on @karczex and @lukaszstolarczuk)
hmm for internal use it might be handy, e.g. (like here) for tests...
Set initial persisted timestamp to INVALID_TIMESTAMP and use (acquire from mpmc queue) timestamps starting from 'INVALID + 1'. From now on, committed/persisted timestamp will mean "the last committed/persisted timestamp", not "one above" as it was previously.
In some cases '0' could be set improperly as a timestamp and such entry could have been counted as a proper entry. So now there's an additional verification if the currently checked entry isn't timestamped with 'INVALID_TIMESTAMP'.
This change is