Skip to content

Conversation

NickCraver
Copy link
Collaborator

In Linux, we see 15 minute socket stalls due to OS-level TCP retries. What this means is the PhysicalConnection detects no issues on the pipe that's retrying, but is also not receiving data at all leading to long stalls in client applications. The goal here is to detect that we're timing out commands people have issued to the connection but we're getting NOTHING back on the socket at all. In this case, we should assume the socket is dead and issue a reconnect so that we get out of the hung situation much faster.

For an initial go at this, we've chosen 4x the timeout interval as a threshold, but could make this configurable if needed.

In Linux, we see 15 minute socket stalls due to OS-level TCP retries. What this means is the PhysicalConnection detects no issues on the pipe that's retrying, but is also not receiving data at all leading to long stalls in client applications. The goal here is to detect that we're timing out commands people have issued to the connection but we're getting _NOTHING_ back on the socket at all. In this case, we should assume the socket is dead and issue a reconnect so that we get out of the hung situation much faster.

For an initial go at this, we've chosen 4x the timeout interval as a threshold, but could make this configurable if needed.
Also forgot to log timeout count as intended, fixing.
@bkaracivi
Copy link

Hello,
Have you ever faced this issue for 2.6.122 client versions running on Windows Server environment?
Is this change, corrects similar cases for clients on Windows Server?
Thanks in advance

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