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.

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

Always set request timeout on keep-alive connections #2447

Merged
merged 1 commit into from Nov 3, 2016

Conversation

mscdex
Copy link
Contributor

@mscdex mscdex commented Nov 3, 2016

No description provided.

@mscdex
Copy link
Contributor Author

mscdex commented Nov 3, 2016

The changes in 001eae3 would cause the http request timeout to only get set if a new socket was being used. This PR makes sure it gets set even when we're already connected.

I apologize, I meant to slip this into the previous PR when I noticed it a little bit ago.

/cc @simov

@simov
Copy link
Member

simov commented Nov 3, 2016

I can publish another patch no problem, I had to ask you first. So is this good for merging/publishing?

@mscdex mscdex force-pushed the fix-timeout-regression branch 2 times, most recently from 1c27101 to 910d710 Compare November 3, 2016 12:17
001eae3 would erroneously only set http request timeout
if a new socket was being used for the request. This commit
ensures the http request timeout is always set, even on keep-alive
connections.
@mscdex
Copy link
Contributor Author

mscdex commented Nov 3, 2016

It should be good to go now, I've added a test for it.

@simov simov merged commit 6301c90 into request:master Nov 3, 2016
@simov
Copy link
Member

simov commented Nov 3, 2016

Thank you! Published.

@mscdex mscdex deleted the fix-timeout-regression branch November 15, 2016 17:56
pulkitsinghal added a commit to ShoppinPal/vend-nodejs-sdk that referenced this pull request Sep 15, 2017
## Motivation
- Some upstream projects that use `vend-nodejs-sdk` were facing strange
issues where long-running use (after 47 minutes or so) led so a situation
where nodejs would just hang after a POST request.
- There weren't any clear CPU or Memory consumption red flags.
- It seemed more like a bad promise chain or failing to invoke a callback
that often leads nodejs into a forever running state and there's nothing
really going on.

## Solution
Look at the [CHANGELOG](https://github.com/request/request/blob/master/CHANGELOG.md)
for `request` and see if any plausible reasons for trying a module update.

1. request/request#2431
2. request/request#2414
3. request/request#2447
4. request/request#2448

This wasn't an exact science but their descriptions seemed to merit
the dependency upgrade as "at least worth a try"

## Consequences
Dropped support for Node 0.10
request/request#2381
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.

None yet

2 participants