Skip to content

Conversation

@sebastianseilund
Copy link

  • Call initialize_retry_vars() in Connection's constructor, so that retry_delay does not become NaN after multiplying two null values. This resulted in the retry delay always being instant, since calling setTimeout() with NaN is equivalent to calling it with 0 ms.
  • Fixed retry_max_delay logic: The max value should be applied after calculating the next retry_delay. Previously, the connection would allow one delay to be greater than the max. And after that every second delay would be greater than the max, since the code was using > to compare the last retry delay (which was the max) and the max, which would always be false.

- Call `initialize_retry_vars()` in `Connection`'s constructor, so that `retry_delay` does not become `NaN` after multiplying two `null` values. This resulted in the retry delay always being instant, since calling `setTimeout()` with `NaN` is equivalent to calling it with 0 ms.
- Fixed `retry_max_delay` logic: The max value should be applied after calculating the next `retry_delay`. Previously, the connection would allow one delay to be greater than the max. And after that every second delay would be greater than the max, since the code was using `>` to compare the last retry delay (which was the max) and the max, which would always be false.
@jfarrell
Copy link
Contributor

Thanks for the patch @sebastianseilund, closing as #393 has a more complete patch for this and additional issues

@jfarrell jfarrell closed this Mar 19, 2015
@sebastianseilund
Copy link
Author

👍

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.

3 participants