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.

Sign up for GitHub

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

Jump to bottom

fix: awaitable isMaster timeout must respect connectTimeoutMS #2627

Merged
merged 19 commits into from
Dec 1, 2020
Merged

fix: awaitable isMaster timeout must respect connectTimeoutMS #2627

merged 19 commits into from
Dec 1, 2020

Conversation

emadum
Copy link
Contributor

@emadum emadum commented Nov 19, 2020 •
edited
Loading

This PR ensures that awaitable isMaster handshakes respect an unlimited timeout (connectionTimeoutMS=0) as per the SDAM specification section on socket timeouts:

Clients MUST use connectTimeoutMS as the timeout for the connection handshake. When connectTimeoutMS=0, the timeout is unlimited and MUST remain unlimited for awaitable isMaster replies. Otherwise, connectTimeoutMS is non-zero and clients MUST use connectTimeoutMS + heartbeatFrequencyMS as the timeout for awaitable isMaster replies.

NODE-2874

@emadum emadum changed the title test: reproduce NODE-2874 fix: monitor socket timeout should be unlimited when connectTimeoutMS=0 Nov 19, 2020
@emadum emadum changed the title fix: monitor socket timeout should be unlimited when connectTimeoutMS=0 fix: make monitor socket timeout unlimited when connectTimeoutMS=0 Nov 19, 2020
emadum and others added 5 commits November 19, 2020 13:13
@emadum
Merge remote-tracking branch 'origin/3.6' into NODE-2874/fix-monitor-…
2ed4ac4 
…timeout
@emadum
potential fix for failing test
a86b383
@emadum
Merge remote-tracking branch 'origin/3.6' into NODE-2874/fix-monitor-…
010a3bd 
…timeout
@emadum
Merge remote-tracking branch 'origin/3.6' into NODE-2874/fix-monitor-…
050d8b0 
…timeout
@mbroadst @emadum
fix: transition topology state before async calls
fc178e2 
When the legacy ReplSet and Server topology types are destroyed
they transition their internal state after a potentially long async
close process has completed. With the recently introduced infinite
default socket timeout, we are hitting this race condition more
consistently. This patch ensures the types transition their state
immediately, reducing the chance that such race conditions can
occur.

NODE-2916
@emadum emadum marked this pull request as ready for review November 28, 2020 23:36
@emadum emadum requested review from mbroadst and nbbeeken November 30, 2020 13:48
@emadum emadum changed the title fix: make monitor socket timeout unlimited when connectTimeoutMS=0 fix: awaitable isMaster timeout must respect connectTimeoutMS Nov 30, 2020
@emadum emadum requested a review from mbroadst December 1, 2020 01:20
mbroadst
mbroadst approved these changes Dec 1, 2020
View reviewed changes
Copy link
Member

@mbroadst mbroadst left a comment

Choose a reason for hiding this comment

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

LGTM

@emadum emadum merged commit b365c50 into 3.6 Dec 1, 2020
@emadum emadum deleted the NODE-2874/fix-monitor-timeout branch December 1, 2020 17:12
@emadum emadum mentioned this pull request Dec 1, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@nbbeeken nbbeeken nbbeeken approved these changes

@mbroadst mbroadst mbroadst approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@emadum @mbroadst @nbbeeken