You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Linux 7c903542320e 3.10.0-1160.102.1.el7.x86_64 #1 SMP Tue Oct 17 15:42:21 UTC 2023 x86_64 GNU/Linux
Subsystem
http
What steps will reproduce the bug?
This issue is triggered by using an http agent with a timeout set. It requires many requests such that sockets are reused. The requests must also take longer than the keep-alive:timeout value sent back by the server. For instance if the agent timeout is set to 30 seconds, but the keep-alive value is 5 seconds, later requests timeout after 5 seconds instead of 30 seconds.
How often does it reproduce? Is there a required condition?
It consistently happens under load when responses take longer than 5 seconds (which is a typical keep-alive:timeout value) and the agent timeout is set to a longer duration.
What is the expected behavior? Why is that the expected behavior?
The expected behavior is that the agent timeout is used.
What do you see instead?
"Connection reset" is reported; although, the connection is not reset, and the client simply aborts the request.
Additional information
The socket timeout for agent sockets seems to be set to the agent keep alive (or server keep-alive:timeout) value so that it will be closed after the timeout (correctly).
When the socket is used again, it keeps that setting. Instead it should use the configured agent timeout. The server's keep-alive:timeout is only for idle connections, not for pending requests.
The _http_agent.js setRequestSocket function does set the timeout when a socket is reused but it has a if (req.timeout === undefined || req.timeout === agentTimeout) guard that often prevents resetting the timeout. Instead of comparing the req.timeout, it seems it should compare the request timeout to the socket timeout, setting the socket timeout if they are different.
A work around for this would be:
request.on('socket', s => {
s.setTimeout(agent.options.timeout);
});
The text was updated successfully, but these errors were encountered:
Version
v20.12.2
Platform
Linux 7c903542320e 3.10.0-1160.102.1.el7.x86_64 #1 SMP Tue Oct 17 15:42:21 UTC 2023 x86_64 GNU/Linux
Subsystem
http
What steps will reproduce the bug?
This issue is triggered by using an http agent with a timeout set. It requires many requests such that sockets are reused. The requests must also take longer than the keep-alive:timeout value sent back by the server. For instance if the agent timeout is set to 30 seconds, but the keep-alive value is 5 seconds, later requests timeout after 5 seconds instead of 30 seconds.
How often does it reproduce? Is there a required condition?
It consistently happens under load when responses take longer than 5 seconds (which is a typical keep-alive:timeout value) and the agent timeout is set to a longer duration.
What is the expected behavior? Why is that the expected behavior?
The expected behavior is that the agent timeout is used.
What do you see instead?
"Connection reset" is reported; although, the connection is not reset, and the client simply aborts the request.
Additional information
The socket timeout for agent sockets seems to be set to the agent keep alive (or server keep-alive:timeout) value so that it will be closed after the timeout (correctly).
When the socket is used again, it keeps that setting. Instead it should use the configured agent timeout. The server's keep-alive:timeout is only for idle connections, not for pending requests.
The _http_agent.js setRequestSocket function does set the timeout when a socket is reused but it has a
if (req.timeout === undefined || req.timeout === agentTimeout)
guard that often prevents resetting the timeout. Instead of comparing the req.timeout, it seems it should compare the request timeout to the socket timeout, setting the socket timeout if they are different.A work around for this would be:
The text was updated successfully, but these errors were encountered: