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

etcdctl: use user specified timeout value #3518

Closed
wants to merge 1 commit into from

Conversation

mitake
Copy link
Contributor

@mitake mitake commented Sep 14, 2015

etcdctl should use a timeout value specified with the option --timeout

Fixes #3517

If the current behavior is intentional, please ignore it.

@mitake
Copy link
Contributor Author

mitake commented Sep 14, 2015

On the second thought, c.GlobalDuration("timeout") seems to be passed to the transport layer correctly. Is just using context.Background() or context.WithCancel() in etcdctl commands enough?

@xiang90
Copy link
Contributor

xiang90 commented Sep 14, 2015

After reading through the code, I think etcdctl correctly set the timeout to every client.

That timeout is a pre request timeout. etcdctl might send out multiple requests if it fails to connection the first few endpoints.

What you have changed is a total timeout for the RPC. We have not defined the flag for that timeout yet.

@mitake
Copy link
Contributor Author

mitake commented Sep 14, 2015

Yes, per request timeout seems to be configured correctly. However, current etcdctl use 1s as total timeout for RPC and it causes unreasonable timeout (I found this issue with testing with this tool: https://github.com/osrg/earthquake , the tool can test various execution pattern of distributed systems. I'll share the test code later). It means even user passes --timeout 5s, etcdctl causes timeout in 1s.

Therefore I think providing a flag for configuring timeout of whole RPC or not configuring timeout would be reasonable. How do you think?

@yichengq
Copy link
Contributor

It means even user passes --timeout 5s, etcdctl causes timeout in 1s.

The client.DefaultRequestTimeout is 5s, so etcdctl should cause timeout in 5s. Do you observe 1s behavior?

@xiang90
Copy link
Contributor

xiang90 commented Sep 14, 2015

@yichengq But we should support total-timeout right?

@yichengq
Copy link
Contributor

@xiang90 Yes. 5s could be a default value, and users could customize the total timeout.

@mitake
Copy link
Contributor Author

mitake commented Sep 14, 2015

@yichengq sorry, the concrete value of the timeout would be different. However, I observed unexpected behavior of timeout during my testing.

@xiang90 How do you think about a new flag like --total-timeout for this purpose?

@mitake
Copy link
Contributor Author

mitake commented Sep 14, 2015

Or should etcdctl remove total timeout (allow unbounded timeout for total execution time)?

@xiang90
Copy link
Contributor

xiang90 commented Sep 14, 2015

@mitake I would suggest a 5 second default total-timeout and make the total-timeout also a flag and configurable.

etcdctl should use a user specified timeout value. This commit adds a
new option --total-timeout to the command. The value passed via this
option is used as a timeout value of entire RPC (API call of client).

Fixes etcd-io#3517
@mitake
Copy link
Contributor Author

mitake commented Sep 15, 2015

@xiang90 @yichengq updated tihs PR, added --total-timeout for entire RPC (client API call) execution

@@ -40,6 +40,7 @@ func main() {
cli.StringFlag{Name: "ca-file", Value: "", Usage: "verify certificates of HTTPS-enabled servers using this CA bundle"},
cli.StringFlag{Name: "username, u", Value: "", Usage: "provide username[:password] and prompt if password is not supplied."},
cli.DurationFlag{Name: "timeout", Value: time.Second, Usage: "connection timeout per request"},
cli.DurationFlag{Name: "total-timeout", Value: time.Second * 5, Usage: "timeout of entire RPC execution"},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5 * time.Second

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

timeout for the command execution (except watch)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5 * time.Second

ok, I'll fix.

timeout for the command execution (except watch)

Actually the timeout value corresponds to one RPC (functions defined in client/). If we call the RPC (potentially which can consist multiple requests?) as command, your description is right. However, I'm not sure it is suitable or not.

Or should we use one context object per one command execution? I think this direction would be natural for users.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or should we use one context object per one command execution? I think this direction would be natural for users.

I think so.

@mitake
Copy link
Contributor Author

mitake commented Sep 15, 2015

I created a new PR for this problem: #3530

Could you review the new one? The contents of two PR are so different.

@mitake mitake closed this Sep 15, 2015
@mitake mitake deleted the timeout branch December 30, 2015 17:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants