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

clientv3: how watch know the remote etcd is closed? #5985

Closed
siddontang opened this issue Jul 19, 2016 · 12 comments
Closed

clientv3: how watch know the remote etcd is closed? #5985

siddontang opened this issue Jul 19, 2016 · 12 comments

Comments

@siddontang
Copy link
Contributor

Hi
I start on etcd node and use the simple watch example here https://godoc.org/github.com/coreos/etcd/clientv3#example-Watcher--Watch

but when I kill etcd server, I find that we can't know the server is down and watch still hangs up.
Do we have any way to check server is down in watch?

@xiang90
Copy link
Contributor

xiang90 commented Jul 19, 2016

You should kill the listener, then the stream will be shutdown. Or you can enable progressNotify to do application level heartbeat.

@heyitsanthony
Copy link
Contributor

Watch isn't really meant for detecting disconnects. Maybe use a Session?

@siddontang
Copy link
Contributor Author

@xiang90

I call embed etcd Close, and I think it will close the listener too, but watch doesn't know it.
I use clientv3.WithProgressNotify() in watch, but seem no help too.

@xiang90
Copy link
Contributor

xiang90 commented Jul 20, 2016

@siddontang After enabling with progress notify, the watcher should expect to receive notification at least every minute. If it cannot receive anything, you should kill it. Watch is designed to handle connection failures, so it just keep on retrying. @heyitsanthony Shall we expose the errors by adding a errc chan?

@xiang90
Copy link
Contributor

xiang90 commented Jul 20, 2016

@siddontang Also as @heyitsanthony mentioned, watch is not really designed for detecting connection issues.

@heyitsanthony
Copy link
Contributor

@xiang90 I don't think Watch should say anything about disconnects; it's at the wrong network layer. The feature probably belongs in the balancer.

@xiang90
Copy link
Contributor

xiang90 commented Jul 20, 2016

@heyitsanthony I do not mean watcher API. I mean for the client interface, we probably should expose some errorc. So the user can know the client is experiencing connection errors.

@heyitsanthony
Copy link
Contributor

@xiang90 sure, agreed

@xiang90
Copy link
Contributor

xiang90 commented Aug 1, 2016

Answers are provided. So I am closing this.

@xiang90 xiang90 closed this as completed Aug 1, 2016
@siddontang
Copy link
Contributor Author

Hi @xiang90
Can we know the connection error in watch now?

@heyitsanthony
Copy link
Contributor

@siddontang is there a reason why Session wouldn't work for your use case? I don't think Watch should ever report transport errors.

@siddontang
Copy link
Contributor Author

@heyitsanthony we need to watch a key changed, Session may be not ok.
But we are refactoring our code, maybe we will remove watch don't need this later. :-)

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

No branches or pull requests

3 participants