[ADDED] Option that disables fast producer stalling (drops msg instead) #6500
+238
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Normally, when a producer detects that one of the consumer of a message is falling behind, it will stall. Which means that if a message has 2 consumers and the first is "slow", then it will affect the timely delivery to the second consumer. With the new option `no_fast_producer_stall=true`, the server will simply drop a message destined to a consumer that would have caused the producer to stall. The message is still delivered to consumers that are not falling behind. The option can be config-reload'ed and if a message is dropped due to fast-producer/slow-consumer, and the message was traced (with deliver option), then the message trace egress event will have an error indicating the reason why the message was not delivered. Resolves #6413 Signed-off-by: Ivan Kozlovic <[email protected]>
kozlovic
requested review from
derekcollison,
neilalexander and
MauriceVanVeen
neilalexander
added a commit
that referenced
this pull request
Feb 12, 2025
kozlovic
added a commit
that referenced
this pull request
Feb 12, 2025
Consolidated the 2 tests into 1, reducing run time from 7-15 sec down to less than 0.4 second and memory usage from 1GB+ down to 18M or so (which is likely not even the usage for the test itself but the sublist tests). Signed-off-by: Ivan Kozlovic <[email protected]>
kozlovic
added a commit
to kozlovic/nats.docs
that referenced
this pull request
Feb 13, 2025
This is related to nats-io/nats-server#6500 Signed-off-by: Ivan Kozlovic <[email protected]>
derekcollison
added a commit
that referenced
this pull request
Feb 13, 2025
Consolidated the 2 tests into 1, reducing run time from 7-15 sec down to less than 0.4 second and memory usage from 1GB+ down to 18M or so (which is likely not even the usage for the test itself but the sublist tests). Signed-off-by: Ivan Kozlovic <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Normally, when a producer detects that one of the consumer of a message is falling behind, it will stall. Which means that if a message has 2 consumers and the first is "slow", then it will affect the timely delivery to the second consumer.
With the new option
no_fast_producer_stall=true, the server will simply drop a message destined to a consumer that would have caused the producer to stall. The message is still delivered to consumers that are not falling behind.The option can be config-reload'ed and if a message is dropped due to fast-producer/slow-consumer, and the message was traced (with deliver option), then the message trace egress event will have an error indicating the reason why the message was not delivered.
Resolves #6413
Signed-off-by: Ivan Kozlovic [email protected]