-
Notifications
You must be signed in to change notification settings - Fork 9.7k
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
refresh a ttl node #1232
Comments
Thanks for fixing this. This is super useful. |
Also is it possible to know the time by which this feature may be available? |
@defunctzombie We do not store the original TTL in etcd. The TTL is transformed into a time stamp in the future. So, the API would need to be:
We would not be able to support leaving off the TTL. |
I assumed the TTL was stored since I seem to get it back when I do a request for a given key. Would be fine if that had to be specified. |
+1 Really want this to happen sooner though! |
👍 |
Is it expected that this new operation would or would not affect the modifiedIndex? I'd prefer not to have all my watchers get triggered when I'm just refreshing a TTL and not changing data. As it stands now, my watchers have to be much more complex than they need to be, as their watches fire everytime I heartbeat a node and update it's ttl. |
This is a very exciting feature. I'm looking for a solution for heart beating service in etcd and this is the best one I believe. |
Any update on this one ? |
Also giving +1 as using ETCD as service registry generates many updates because of TTL refreshing which needs to by filtered as "uninteresting" configuration changes. |
It might be insightful to describe how Zookeeper solves this problem. Zookeeper has ephemeral nodes, which instead of having a TTL, have a lifetime scoped to the TCP connection that created them. When that connection is closed or times out, all the ephemeral nodes it created are destroyed. This seems pretty elegant, mapping pretty well to the use case of a service registry. I do wonder though what time out semantics Zookeeper guarantees, if any: depending on the host's TCP stack settings, connections might take a very long time to time out. And of course, there's the issue that Etcd in common usage may not involve any persistent connection since that wouldn't be very Perhaps it would still be useful to have some other object to which a similar concept of ephemeral nodes can be bound? Maybe my service registration agent could look like this:
When the registration agent stops heartbeating and the timeout expires, or explicitly removes the client key, all the ephemeral nodes associated with it are deleted. A nice advantage here is that etcd client libraries can handle the client key creation and heartbeating orthogonally, so a service registration implementation may not need to actually have any heartbeating logic. If that's not possible (maybe you are just using |
I do not quite like the idea to attach a session to a TCP connection. That means only one TCP connection can maintain that session. The ownership of the session is kind of too fixed. It limites mechanism for ownership transfer and session maintenance by multiple entities. We do have the plan to make this elegant in etcd. |
Any update on this one? We're using Etcd for service discovery, and we have our services periodically refresh their registrations. The same registrations are watched by SkyDNS, and other discovery software for updates. We currently use It would be a really nice solution to have |
Any update? |
I really need this feature on an heavy online envrionment. I'd like to implement it. @xiang90 Is there any docs telling me where can I start? I noticed there is a branch named dev-2.2. I think this maybe the next release version. Am I right ? I indeed can not wait for |
@shafreeck @YanXiaoping I am afraid this feature is still not ok. And the latest code is on the |
@adohe is correct. |
@adohe Are you working on this ? How is the progress now ? I am going to keep watching on this feature, @adohe @xiang90 Could you guys supply some documents about this feature ? I am willing to get some details about the implementation of this feature, then I can make a self-using patch based on dev-2.2 and keep compatible with the I am sad to hear that the api will only be added into v3 api. Maybe I should work around this using the "refresh directory" way at least now. |
@xiang90 any progress on this? I am afraid it is a little bit difficult for people make self-using patch and keep compatible with the |
I don't understand why ? The API has big changes ? |
For people looking for this in 2.x, I've put together a preliminary implementation. Adding refresh=true to PUT/POST options when updating a TTL will no longer fire a watch notification (unless a value change occurs with the TTL update) Commit: Example: curl http://127.0.0.1:2379/v2/keys/foo -XPUT -d value=bar -d ttl=5 -d refresh=true -d prevExist=true I've included tests, and done some local testing but if anyone wants to do some testing that would be great. I doubt that this would get included in the upstream 2.x branch at this point, but if it's possible I'll go ahead and create a pull request after additional testing and finishing some TODOs TODO: Add support for this to the client and etcdctl |
Adding our +1 to implementing this in the client API as soon as possible. The TTL is a fantastic feature, but for service discovery and keep-alive in a large microservice environment the load so many real updates would levy on Etcd is of great concern. Having some kind of "I'm still OK" capability without updating indexes and watchers would be awesome. Loving it otherwise guys! Great work. |
+1 really need this for service discovery |
+1 Wish this feature could be implemented in the release version ASAP. |
+1 |
2 similar comments
+1 |
+1 |
@xiang90 are we going to replace TTL feature with lease in v3? |
@adohe Yes. |
@xiang90 how about the lease in v3? complete? I have not seen etcd code for a long time, guess can I have a try about lease? |
I am closing this issue since:
|
Sorry, may I know when this "v3" will be available? (or where could I find this info?) |
@YanXiaoping you can experiment with the V3 API using the |
@jonboulle , ok, thank you! |
Reference issue: #385 (comment)
I am working on a service registry module on top of etcd and one of the things I really like from etcd is the TTL feature. It seems that there should also be a way to refresh the TTL without updating the value, This would allow the registered service to continue announcing its presence. Right now I can accomplish this using a
PUT /v2/keys/foobar?value=<old value>&prevExist=true
but that requires that I continue specifying the old value. It would be nice to be able to just refresh a key.Some apis that might accomplish this:
Simple refresh with no TTL change.
Reset the TTL to a new value
These would require that the key already exists and would imply
prevExist=true
.The text was updated successfully, but these errors were encountered: