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

Allow turn off of doReqAsync adaptive timeout #1152

Merged
merged 3 commits into from
Sep 18, 2024
Merged

Conversation

mprimi
Copy link
Contributor

@mprimi mprimi commented Sep 12, 2024

doReqAsync uses an adaptive timeout to stop listening for responses when the number of responses waited is zero.

In this PR:

  • Create special value waitFor=-1 to wait for the full timeout for responses
  • Update audit gather wait for the full timeout

Copy link
Collaborator

@ripienaar ripienaar left a comment

Choose a reason for hiding this comment

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

small change only

cli/util.go Outdated
// Unless:
// - We are waiting for a specific number of responses (finisher is null) OR
// - We were told explicitly to wait for the full interval for responses
if finisher != nil && waitFor != doReqAsyncWaitTimeoutInterval {
Copy link
Collaborator

Choose a reason for hiding this comment

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

wouldn't finisher always be nil if waitFor is -1, so just checking if finisher != nil should be sufficient here, if not we should restructure things that the nil check is sufficient, easy to miss multiple places to update if this behaviour changes in future again.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Actually sorry above is probsbly incorrect. Better behaviour for -1 would be advancing the timer here by opts.Timeout instead of 300ms. Thats it.

This way you get the behaviour if handling responses while they are coming and then getting a 2s by default idle period at the end to allow for slow ones.

Would overall make things slower when there are bad networking interactions but big improvement to reliability and a way to adjust that using the timeout option.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The default timeout is 5s, so waits 5 extra seconds from the last response.

I think "stop doing smart things and just wait a fixed amount of time" is a more useful "alternative mode" for this utility function.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Still convinced you should just write your own request method. They have different goals.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Please take a look at the latest content of the PR, I rolled back all my changes to this function because it already handles "wait for full timeout" if i just pass a negative number.

So I'm just creating a dummy value to make that a little more explicit.

@mprimi mprimi changed the title Tweak doReqAsync to turn off adaptive timeout Allow to turn off doReqAsync adaptive timeout Sep 16, 2024
@mprimi mprimi changed the title Allow to turn off doReqAsync adaptive timeout Allow turn off of doReqAsync adaptive timeout Sep 16, 2024
cli/util.go Show resolved Hide resolved
When doReqAsync is invoked without a positive 'waitFor' value,
it uses a simple adaptive timeout to avoid waiting the full interval
(default 5s).

This change creates a constant which can be passed into 'waitFor' to
disable adaptive timeout and wait for the full interval for responses.
Disable the adaptive responses timeout and wait for the full interval
for answers to ping from servers.
@ripienaar ripienaar merged commit 026bd58 into nats-io:main Sep 18, 2024
2 checks passed
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