Restart stale watch threads where they left off #275
Conversation
agrare
force-pushed
the
restart_stale_watch_threads
branch
2 times, most recently
from
47e6ec6 to
82855bc
Compare
If a watch thread fails for any reason (exception, timeout, etc...) restart it with the last resourceVersion so it picks up where it left off.
agrare
force-pushed
the
restart_stale_watch_threads
branch
from
82855bc to
34a4a0a
Compare
|
Checked commit agrare@34a4a0a with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
|
@cben going from your linked comment kubernetes/website#6540 (comment) I'm setting the collection resourceVersion to the latest notice.object's resourceVersion. Does this look like a valid approach? |
cben
left a comment
cben
left a comment
There was a problem hiding this comment.
Looks good.
You could drop start_watch_threads and always use ensure_watch_threads; ok to keep both if you want the prettier "Starting" vs "Restarting" logging.
| # object's resourceVersion so that if this watch has to be restarted | ||
| # it will pick up where it left off. | ||
| resource_version = notice.object.metadata.resourceVersion | ||
| resource_versions[entity_type] = resource_version |
There was a problem hiding this comment.
this updates a shared hash (at distinct keys) from multiple threads, is that fully safe in ruby?
There was a problem hiding this comment.
Yeah I'll use a Concurrent::Hash to be safe
|
Merging. I'll be on vacation all next week so will try to unblock as much stuff as possible today. |
3 participants
If a watch thread fails for any reason (exception, timeout, etc...)
restart it with the last resourceVersion so it picks up where it left
off.