-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent reserved bytes underflow #2907
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you mind adding the following tests?
- Reserve 2/3rd of the total account limit, then update to one extra byte.
- Reserve 2/3rd of the total server limit, then update to one extra byte.
I believe we may have an accounting issue there as well.
These two scenarios apply to going down by a byte as well.
0bab56d
to
cae9d96
Compare
3bb9e5f
to
bf877d8
Compare
The newer commits add the following new tests. They caught some bugs, so the original handling of MaxBytes was also updated.
|
Added more tests to verify that the leader's system limits don't override non-leader server's limits.
|
fbe1431
to
278fdec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Added new tests where we create a supercluster and ensure we can't create a large MaxBytes stream on a smaller cluster.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Currently, there is a bug where
js.storeReserved
andjs.memReserved
can underflow, causing/varz
metrics to be incorrect. Below is a history of the state changes.js.storeReserved
→ 0js.storeReserved
→ 0 (should have reserved 1234)js.storeReserved
→ -1234Bug:
js.storeReserved=-1234
is anint
that later gets converted to auint64
, which causes an underflow.This change releases the old MaxBytes and reserves the new MaxBytes during the stream update step. This way, when a stream is deleted, these values don't become negative.
Resolves #2882 (see for additional info)