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

net/rpc: expected Timeout based alternatives to functions for rpc.Dial, rpc.DialHTTP, rpc.DialHTTPPath [proposal]. #15236

Closed
harshavardhana opened this issue Apr 11, 2016 · 2 comments

Comments

@harshavardhana
Copy link
Contributor

Please answer these questions before submitting your issue. Thanks!

  1. What version of Go are you using (go version)?

go1.6

  1. What operating system and processor architecture are you using (go env)?

linux/amd64

  1. What did you do?

Just using rpc.DialHTTP, rpc.Dial from an rpc client.

  1. What did you expect to see?

Expected Timeout based functions for rpc.Dial, rpc.DialHTTP, rpc.DialHTTPPath.

  1. What did you see instead?

Default functions like rpc.Dial, rpc.DialHTTP, rpc.DialHTTPPath use just net.Dial which is a dialer without any timeout, this ends up waiting too long on all operating systems leading to a perception that something is hung. It would be nicer to have a timeout based dialer for 'rpc' client, since a failover, or error could be reported to user during a disconnect can be achieved in a quick manner.

This is just a proposal, feel free to close if this is intentional to not provide timeout based dialers for rpc.

@bradfitz
Copy link
Contributor

Related: #7946 (and see https://go-review.googlesource.com/#/c/17271/)

@adg
Copy link
Contributor

adg commented Sep 26, 2016

We don't want to do this, in light of #16844. Thanks for your time.

@adg adg closed this as completed Sep 26, 2016
@golang golang locked and limited conversation to collaborators Sep 26, 2017
@rsc rsc unassigned robpike Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants