Skip to content

[FIXED] Subject state consistency#6226

Merged
derekcollison merged 1 commit intomainfrom
maurice/subject-state-consistency
Dec 6, 2024
Merged

[FIXED] Subject state consistency#6226
derekcollison merged 1 commit intomainfrom
maurice/subject-state-consistency

Conversation

@MauriceVanVeen
Copy link
Copy Markdown
Member

Subject state would not always remain consistent given a specific pattern of message removals.

There were three bugs:

  • recalculateFirstForSubj in memstore would do startSeq+1, but filestore would always just start at mb.first.seq. These are now consistent.
  • recalculateFirstForSubj was not called when ss.Msgs == 1, which could mean we had a stale ss.FirstSeq if it needed to be recalculated.
  • If after recalculation it turns out ss.FirstSeq equals the message we're trying to remove, we need to recalculateFirstForSubj again, since ss.Last is also lazy and could be incorrect.

Apart from that, filestore and memstore are now both equivalent when it comes to first updating per-subject state and then removing the message, as well as removeSeqPerSubject and how it updates the subject state.

Signed-off-by: Maurice van Veen github@mauricevanveen.com

// Always reset.
ss.First, ss.Last, ss.Msgs = 0, 0, 0

if filter == _EMPTY_ {
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is redundant, if isAll := filter == _EMPTY_ || filter == fwcs we early return above.

Copy link
Copy Markdown
Member

@derekcollison derekcollison left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Signed-off-by: Maurice van Veen <github@mauricevanveen.com>
@MauriceVanVeen MauriceVanVeen force-pushed the maurice/subject-state-consistency branch from 06983f6 to 283b607 Compare December 6, 2024 18:47
fs.removePerSubject(sm.subj)
// Need to mark the sequence as deleted. Otherwise, recalculating ss.First
// for per-subject info would be able to find it still.
smb.dmap.Insert(mseq)
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another important addition; TestFileStoreExpireMsgsOnStart was failing as it relied on the bug existing. Now that the bug is gone, we need to actually mark the sequence as deleted. Otherwise, mb.recalculateFirstForSubj could still find and select that sequence.

@MauriceVanVeen MauriceVanVeen marked this pull request as ready for review December 6, 2024 19:33
@MauriceVanVeen MauriceVanVeen requested a review from a team as a code owner December 6, 2024 19:33
@derekcollison derekcollison merged commit 60e2982 into main Dec 6, 2024
@derekcollison derekcollison deleted the maurice/subject-state-consistency branch December 6, 2024 19:35
neilalexander added a commit that referenced this pull request Dec 13, 2024
Includes the following:

- #6226
- #6232
- #6235
- #6064
- #6244
- #6246
- #6247
- #6248
- #6250

Signed-off-by: Neil Twigg <neil@nats.io>
MauriceVanVeen added a commit that referenced this pull request Dec 13, 2024
This reverts commit 60e2982, reversing
changes made to f264fb3.
wallyqs pushed a commit that referenced this pull request Dec 13, 2024
This reverts commit 60e2982, reversing
changes made to f264fb3.
wallyqs added a commit that referenced this pull request Dec 13, 2024
MauriceVanVeen pushed a commit that referenced this pull request Dec 17, 2024
Subject state would not always remain consistent given a specific
pattern of message removals.

There were three bugs:
- `recalculateFirstForSubj` in memstore would do `startSeq+1`, but
filestore would always just start at `mb.first.seq`. These are now
consistent.
- `recalculateFirstForSubj` was not called when `ss.Msgs == 1`, which
could mean we had a stale `ss.FirstSeq` if it needed to be recalculated.
- If after recalculation it turns out `ss.FirstSeq` equals the message
we're trying to remove, we need to `recalculateFirstForSubj` again,
since `ss.Last` is also lazy and could be incorrect.

Apart from that, filestore and memstore are now both equivalent when it
comes to first updating per-subject state and then removing the message,
as well as `removeSeqPerSubject` and how it updates the subject state.

Signed-off-by: Maurice van Veen <github@mauricevanveen.com>
wallyqs pushed a commit that referenced this pull request Dec 17, 2024
Subject state would not always remain consistent given a specific
pattern of message removals.

There were three bugs:
- `recalculateFirstForSubj` in memstore would do `startSeq+1`, but
filestore would always just start at `mb.first.seq`. These are now
consistent.
- `recalculateFirstForSubj` was not called when `ss.Msgs == 1`, which
could mean we had a stale `ss.FirstSeq` if it needed to be recalculated.
- If after recalculation it turns out `ss.FirstSeq` equals the message
we're trying to remove, we need to `recalculateFirstForSubj` again,
since `ss.Last` is also lazy and could be incorrect.

Apart from that, filestore and memstore are now both equivalent when it
comes to first updating per-subject state and then removing the message,
as well as `removeSeqPerSubject` and how it updates the subject state.

Signed-off-by: Maurice van Veen <github@mauricevanveen.com>
wallyqs added a commit that referenced this pull request Jan 9, 2025
#### Dependencies
- #6323
- #6324

####  Leafnode
- #6291

#### JetStream
- #6226
- #6235
- #6277
- #6279
- #6283
- #6289
- #6316
- #6317
- #6325
- #6326
- #6335
- #6338
- #6341
- #6344
- #6150
- #6351
- #6355

#### Tests
- #6278
- #6297
- #6300
- #6343
- #6329
- #6330
- #6331
- #6332
- #6334
- #6356
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants