-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Stop all informers is calling start watcher #3029
Stop all informers is calling start watcher #3029
Conversation
Can one of the admins verify this patch? |
cc10a4c
to
d62b193
Compare
@rohanKanojia @akram my understanding of where things stand now is that the initially created Watch should not be terminated unless explicitly closed. If this is correct, then stopping the watch is appropriate only on the non-exceptional onClose. You could also just reuse the existing stop method here. I've made some related cleanups in #3048 |
@@ -111,6 +111,15 @@ private void reListAndSync() { | |||
} | |||
} | |||
|
|||
private void stopWatcher() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's reuse the existing stop method instead of introducing a new method.
Then in the ReflectorWatcher.onClose(WatcherException exception) method, remove the call to onClose.run. Based upon #3018 the watch should just be left in place to keep retrying.
Thinking about it more though, after the relist you do need to restart the watch at the new latest resource version. So the changes I'm describing here a bit more pervasive. Let me apply your pr and layer some changes on top of that for clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, so, I will update my PR to call the stop
method instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@akram sorry, I didn't go back and update all of my comments - we don't want to call stop as written.
this incorporates the reflector changes from fabric8io#3029 It goes further in refining responsibilities by mostly relying on the watch for tracking the lastResourceVersion and removing onClose behavior that is no longer necessary due to fabric8io#3018
@akram shawkins#1 builds upon #3048 and adds your Reflector changes (the utils changes are not there). This tries to further clean up the responsibilities in the code - as a lot of what the Reflector was assuming is already handled. |
d62b193
to
2fc4ead
Compare
…watcher and not re-open it
2fc4ead
to
d7ced42
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thx!
@manusa @akram based upon what my understanding with with working shawkins#1 - the most consistent solution here is to only have the current watcher perform a list, sync, and watch on an exceptional onClose. No action is needed from the Watcher non-exceptional onClose method - that will only be called when the Watch is explicitly closed, which can only be called via the the Reflector. There is no need for the Watcher to call back into the Reflector in that case. |
Kudos, SonarCloud Quality Gate passed! |
Hi @shawkins, just to be clear, your #3048 + the additional PR supersedes this one (#3029)? Should this one be closed in favor of yours? (Also #3048 is marked as ready, but has your internal outstanding PR --> shawkins#1. Is it ready?) |
@manusa #3048 by itself is ready. shawkins#1 supersedes the reflector changes from here. Can we have this pr narrowed to just the util changes? On shawkins#1 - that may need some refinement. I'm also trying to reuse the resource version from the Watch itself - but that isn't required for just the change to the onClose behavior. |
Also I know that we've started down the path of having the Watcher indicate that it's reconnecting. FWIW in looking at the go client they do have a more formal concept of a RetryWatcher https://github.com/kubernetes/client-go/blob/f6ce18ae578c8cca64d14ab9687824d9e1305a67/tools/watch/retrywatcher.go that this logic may have been originally based upon. If preferred we can try to take things in that direction instead. |
#3055 addresses the same issue as the Reflector changes here. |
#3048 was merged yesterday. I think that the next one to be merged in the Shared Informer stack is this one. Could you please resolve the conflicts or maybe create a superseding PR which includes @akram changes + shawkins#1 (@shawkins) ---> Whatever works best |
@akram you should remove the reflector changes from this pr. The util changes are still applicable if you want them. |
Relates to: #2010 |
This pr will be completely out-of-date if #3169 is accepted. |
All of the changes in this pr have now been addressed. |
Description
The
onClose
method reference was pointing tostartWatcher
method which was causing a new watcher to be started when thestopAllRegisteredInformers
was called. ThestartWacher
was containing a sleep of 5 seconds causing thestopAllRegisteredInformers
to last that long.This PR changes this method to
stopWatcher
which does only close the watcher.Fixes #3024
It is may be required to update the signature of the class by adding an
onStart
method but, that's beyond the scope of this PR.Type of change
test, version modification, documentation, etc.)
Checklist