-
Notifications
You must be signed in to change notification settings - Fork 543
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
Expose TCP connect() and recv() timeouts for HTTP client #544
Comments
You can use any of the options available to the https://github.com/request/request#requestoptions-callback Including the two |
Thanks, Brendan! Based on the docs that you linked to this appears to be a single parameter, controlling both, connect() and recv() timeout:
We usually want to be able to set those independently -- in most cases we want to set a short connect() timeout and a longer read/recv timeout. Well :-). I'll try playing with that. Thanks again. For the record: the HTTP client situation in the Javascript ecosystem seems to be rather ugly. For example, the HTTP client underlying this library here (no blame) is deprecated an doesn't provide fine-grained timeout control :-). Then there are other HTTP clients that move so fast that there are breaking changes with every release, and then again other HTTP clients that also don't bother much with timeout settings (mikeal/bent#59). I am currently liking https://github.com/sindresorhus/got for its timeout control, but it has other downsides. Having seen some of that I appreciate even more than before the value of ecosystems that offer a mature standard library (and where a large fraction of the community has converged to using the same mature and maintained HTTP client library), where you can just move on and be productive. Ha. |
Say, I want to pass that when calling The current type definition (from
with
which of course results in a I would truly appreciate to work on a 'working example' with you. |
Using this code to try to achieve a connect() timeout of ~10 seconds:
(Note the I was lucky enough to see a connect timeout thereafter:
Notice the time difference here, the connect() timeout did not hit in within ~10 seconds, but more like after ~2 minutes -- which is the "problem" I wanted to address by choosing a custom timeout constant. @brendandburns is there anything obvious I am doing wrong / would you expect the code above to properly forward the |
Should work given your code snippet. I will double check through the code and see if something is going wrong. |
And I hear you on the http client, it's discussed in detail here: Part of the problem is the client generation is tied tightly to a particular HTTP library, and so changing the HTTP library means introducing breaking changes in the client API sigh |
Just a quick updated @brendandburns we kept seeing O(1 min) time to pass before the connect timeout hits in with the above's code. Didn't investigate further though. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
Rotten issues close after 30d of inactivity. Send feedback to sig-contributor-experience at kubernetes/community. |
@fejta-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Relates to #96.
Even if for example a TCP connect() timeout error is supposed to be "left for the user to handle" we need a way to configure the relevant timeout constant for the underlying HTTP client. Same for
recv()
timeout (or "request timeout").The text was updated successfully, but these errors were encountered: