Skip to content
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

Cherry-pick PRs for 2.10.15-RC.3 #5354

Merged
merged 17 commits into from Apr 28, 2024
Merged

Cherry-pick PRs for 2.10.15-RC.3 #5354

merged 17 commits into from Apr 28, 2024

Conversation

wallyqs and others added 17 commits April 25, 2024 16:21
Signed-off-by: Waldemar Quevedo <wally@nats.io>
I made an incorrect comment previously about not needing to check
the cache's result to know if there is a match. I added a test for
that, but also discovered that there was an issue where HasInterest
would incorrectly return true if checking for "foo" when there
is only a subscription on "foo.*". Added more tests.

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Co-authored-by: Jean-Noël Moyne <jnmoyne@gmail.com>
Co-authored-by: Jean-Noël Moyne <jnmoyne@gmail.com>
Co-authored-by: Jean-Noël Moyne <jnmoyne@gmail.com>
If the first INFO never makes it back and for some reasons the
remote also does not close the connection, or connection is half
closed, the outbound would not have detected that the connection
is stale.

The outbound connection cannot send PING before it receives the
INFO from the remote because that is only when the outbound sends
the CONNECT. But the remote will fail if the first protocol from
an outbound is not CONNECT.

Using the same principle that we used for routes with compression
enabled, where PINGs cannot be sent until a certain time in the
handshake, we will use the ping timer to simply close the connection
as stale if the ping timer has not been reset before the time
needed to send the max number of pings.

Resolves #5349

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Signed-off-by: Waldemar Quevedo <wally@nats.io>
We had a bug that would overwrite the sync subject during parallel stream creation which would cause upper layer stream cacthups to fail on server restarts.
We also were reporting first sequence mismatch when we hot max retries to force a reset but this was misleading, so added in proper error for max retires limit.

Signed-off-by: Derek Collison <derek@nats.io>
Consumers could still be catching up as well.

Signed-off-by: Derek Collison <derek@nats.io>
Signed-off-by: Derek Collison <derek@nats.io>
…heck if beyond a minumum threshold.

On an active stream the ack floor periodic checks could trigger just due to normal circumstances, so use minimum threshold.
Also do not jump delivered in that logic based on stream sequences.
And finally do not have leader jump ack floors when pending is empty, this allows consistency checks to be consistent across all replicas.

Signed-off-by: Derek Collison <derek@nats.io>
Signed-off-by: Derek Collison <derek@nats.io>
Signed-off-by: Derek Collison <derek@nats.io>
Signed-off-by: Derek Collison <derek@nats.io>
Signed-off-by: Derek Collison <derek@nats.io>
@wallyqs wallyqs marked this pull request as ready for review April 27, 2024 23:26
@wallyqs wallyqs requested a review from a team as a code owner April 27, 2024 23:26
Copy link
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

@wallyqs wallyqs merged commit 5cca3f1 into release/v2.10.15 Apr 28, 2024
4 checks passed
@wallyqs wallyqs deleted the neil/21015rc3 branch April 28, 2024 00:19
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.

None yet

5 participants