Not respecting timeout #2535

Open
jaggedsoft opened this Issue Feb 9, 2017 · 13 comments

Comments

Projects
None yet
7 participants
@jaggedsoft

jaggedsoft commented Feb 9, 2017

Prior to my last npm update, timeout was working fine. Now it's completely ignoring whatever value I provide. Any ideas?
/proc/sys/net/ipv4/tcp_syn_retries is set to 3

Thanks for this awesome software!!

@talasila66

This comment has been minimized.

Show comment
Hide comment
@talasila66

talasila66 Mar 15, 2017

Any update on the above issue, we are also facing similar issue?

Any update on the above issue, we are also facing similar issue?

@jaggedsoft

This comment has been minimized.

Show comment
Hide comment
@jaggedsoft

jaggedsoft Mar 16, 2017

@talasila66 the fix for me was npm install request@2.65.0
I tested request@2.81.0 and request@2.79.0 and could not trigger the errors:
Error: ETIMEDOUT
Error: ESOCKETTIMEDOUT

I should also note that I'm connecting through a proxy. Timeout seems to function as intended when I'm not

jaggedsoft commented Mar 16, 2017

@talasila66 the fix for me was npm install request@2.65.0
I tested request@2.81.0 and request@2.79.0 and could not trigger the errors:
Error: ETIMEDOUT
Error: ESOCKETTIMEDOUT

I should also note that I'm connecting through a proxy. Timeout seems to function as intended when I'm not

@talasila66

This comment has been minimized.

Show comment
Hide comment
@talasila66

talasila66 Mar 17, 2017

Thanks for the reply @jaggedsoft will test with npm install request@2.65.0 will let you know the update on the same.

Thanks for the reply @jaggedsoft will test with npm install request@2.65.0 will let you know the update on the same.

@addityasingh

This comment has been minimized.

Show comment
Hide comment
@addityasingh

addityasingh Mar 28, 2017

@talasila66 We are also having the same issue for request@2.74.0. Can you confirm which version you were seeing this problem on?

@talasila66 We are also having the same issue for request@2.74.0. Can you confirm which version you were seeing this problem on?

@talasila66

This comment has been minimized.

Show comment
Hide comment
@talasila66

talasila66 Mar 29, 2017

@addityasingh Started Using request@2.81.0 no issues has been observed related to the timeout. Our issue is Exress JS Server has a default configuration of 2 mins response timeout, after that it started sending in complete response.

Hence it looked like request@2.81.0 module not respecting the timeout. Solved by increasing Exress JS Server timeout parameter.

@addityasingh Started Using request@2.81.0 no issues has been observed related to the timeout. Our issue is Exress JS Server has a default configuration of 2 mins response timeout, after that it started sending in complete response.

Hence it looked like request@2.81.0 module not respecting the timeout. Solved by increasing Exress JS Server timeout parameter.

@addityasingh

This comment has been minimized.

Show comment
Hide comment
@addityasingh

addityasingh Mar 29, 2017

Thanks. But doesn't work for me on 2.81.0 or 2.74.0. I will try to check again with 2.81.0

Thanks. But doesn't work for me on 2.81.0 or 2.74.0. I will try to check again with 2.81.0

@ayqy

This comment has been minimized.

Show comment
Hide comment
@ayqy

ayqy Apr 22, 2017

"request": "^2.81.0" has the same error
nginx proxy pass, node restarts many times due to this error, try request@2.65.0

ayqy commented Apr 22, 2017

"request": "^2.81.0" has the same error
nginx proxy pass, node restarts many times due to this error, try request@2.65.0

@ayqy

This comment has been minimized.

Show comment
Hide comment
@ayqy

ayqy Apr 22, 2017

Unfoturnately, these timeout errors are still alive.

# cat /root/.pm2/logs/app-error-0.log
Error: ETIMEDOUT
    at Timeout._onTimeout (app/node/node_modules/request/request.js:808:15)
    at ontimeout (timers.js:386:14)
    at tryOnTimeout (timers.js:250:5)
    at Timer.listOnTimeout (timers.js:214:5)
Error: ESOCKETTIMEDOUT
    at ClientRequest.<anonymous> (app/node/node_modules/request/request.js:825:19)
    at Object.onceWrapper (events.js:293:19)
    at emitNone (events.js:86:13)
    at ClientRequest.emit (events.js:188:7)
    at TLSSocket.emitRequestTimeout (_http_client.js:614:42)
    at Object.onceWrapper (events.js:293:19)
    at emitNone (events.js:91:20)
    at TLSSocket.emit (events.js:188:7)
    at TLSSocket.Socket._onTimeout (net.js:351:8)
    at ontimeout (timers.js:386:14)
Error: read ECONNRESET
    at exports._errnoException (util.js:1050:11)
    at TLSWrap.onread (net.js:581:26)

Is there a way to slove this? HELP!

ayqy commented Apr 22, 2017

Unfoturnately, these timeout errors are still alive.

# cat /root/.pm2/logs/app-error-0.log
Error: ETIMEDOUT
    at Timeout._onTimeout (app/node/node_modules/request/request.js:808:15)
    at ontimeout (timers.js:386:14)
    at tryOnTimeout (timers.js:250:5)
    at Timer.listOnTimeout (timers.js:214:5)
Error: ESOCKETTIMEDOUT
    at ClientRequest.<anonymous> (app/node/node_modules/request/request.js:825:19)
    at Object.onceWrapper (events.js:293:19)
    at emitNone (events.js:86:13)
    at ClientRequest.emit (events.js:188:7)
    at TLSSocket.emitRequestTimeout (_http_client.js:614:42)
    at Object.onceWrapper (events.js:293:19)
    at emitNone (events.js:91:20)
    at TLSSocket.emit (events.js:188:7)
    at TLSSocket.Socket._onTimeout (net.js:351:8)
    at ontimeout (timers.js:386:14)
Error: read ECONNRESET
    at exports._errnoException (util.js:1050:11)
    at TLSWrap.onread (net.js:581:26)

Is there a way to slove this? HELP!

@shuhei

This comment has been minimized.

Show comment
Hide comment
@shuhei

shuhei May 14, 2017

As far as I read the implementation, the timeout option is only applied to inactive socket by request.setTimeout() and the initial socket connection. It was introduced in 001eae3 and v2.77.0, and was not fixed properly in 82da8b8 v2.78.0.

If we want to make it compatible with the documentation, the timeout should be cleared at request's response event. To do that, timeoutTimer has to be set regardless of isConnecting and shouldn't be cleared by socket's connect event.

shuhei commented May 14, 2017

As far as I read the implementation, the timeout option is only applied to inactive socket by request.setTimeout() and the initial socket connection. It was introduced in 001eae3 and v2.77.0, and was not fixed properly in 82da8b8 v2.78.0.

If we want to make it compatible with the documentation, the timeout should be cleared at request's response event. To do that, timeoutTimer has to be set regardless of isConnecting and shouldn't be cleared by socket's connect event.

@shuhei

This comment has been minimized.

Show comment
Hide comment
@shuhei

shuhei May 14, 2017

Also, 1ef4075 v2.76.0 made the timeout cleared at socket connect event, which changed the behavior in the initial socket connection.

shuhei commented May 14, 2017

Also, 1ef4075 v2.76.0 made the timeout cleared at socket connect event, which changed the behavior in the initial socket connection.

@jzastrow

This comment has been minimized.

Show comment
Hide comment
@jzastrow

jzastrow May 22, 2017

We also have problems with very slow long running requests, where the configured timeout seems to be ignored after the first byte was sent.
Is there a way to set a fixed timeout for the whole request cycle?

jzastrow commented May 22, 2017

We also have problems with very slow long running requests, where the configured timeout seems to be ignored after the first byte was sent.
Is there a way to set a fixed timeout for the whole request cycle?

@jura-b

This comment has been minimized.

Show comment
Hide comment
@jura-b

jura-b Jun 1, 2018

Is this problem still persist?

jura-b commented Jun 1, 2018

Is this problem still persist?

@talasila66

This comment has been minimized.

Show comment
Hide comment

no

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment