-
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
should resync be executed in resyncExecutor.scheduleWithFixedDelay instead of resyncExecutor.scheduleAtFixedRate ? #3016
Comments
Is this related to #2977? |
Thanks a lot for investigating this issue. As you pointed out using scheduleWithFixedDelay seems to be producing correct results. behavior with scheduleAtFixedRate. For a resync period of 30 seconds, I see resync happening sometimes after 30 seconds and sometimes after 60 seconds
behavior with scheduleWithFixedDelay. For a resync period of 30 seconds, I'm able to see consistent resync after every 30 seconds:
|
+ When using `resyncExecutor.scheduleAtFixedRate` we're seeing inconsistent resync intervals since it doesn't wait for previous task to be terminated. Hence using `resyncExecutor.scheduleWithFixedDelay` instead. + Remove unused reflectExecutor from Controller and Reflector since we don't use scheduled reflector relist since fabric8io#2964
I also checked client-go docs and seems like scheduleWithFixedDelay is the right choice
https://github.com/kubernetes/client-go/blob/master/tools/cache/shared_informer.go#L148 |
+ When using `resyncExecutor.scheduleAtFixedRate` we're seeing inconsistent resync intervals since it doesn't wait for previous task to be terminated. Hence using `resyncExecutor.scheduleWithFixedDelay` instead. + Remove unused reflectExecutor from Controller and Reflector since we don't use scheduled reflector relist since fabric8io#2964
+ When using `resyncExecutor.scheduleAtFixedRate` we're seeing inconsistent resync intervals since it doesn't wait for previous task to be terminated. Hence using `resyncExecutor.scheduleWithFixedDelay` instead. + Remove unused reflectExecutor from Controller and Reflector since we don't use scheduled reflector relist since fabric8io#2964
+ When using `resyncExecutor.scheduleAtFixedRate` we're seeing inconsistent resync intervals since it doesn't wait for previous task to be terminated. Hence using `resyncExecutor.scheduleWithFixedDelay` instead. + Minor changes in ControllerTest regarding resync expectations/wait time
+ When using `resyncExecutor.scheduleAtFixedRate` we're seeing inconsistent resync intervals since it doesn't wait for previous task to be terminated. Hence using `resyncExecutor.scheduleWithFixedDelay` instead. + Minor changes in ControllerTest regarding resync expectations/wait time
+ When using `resyncExecutor.scheduleAtFixedRate` we're seeing inconsistent resync intervals since it doesn't wait for previous task to be terminated. Hence using `resyncExecutor.scheduleWithFixedDelay` instead. + Minor changes in ControllerTest regarding resync expectations/wait time
+ When using `resyncExecutor.scheduleAtFixedRate` we're seeing inconsistent resync intervals since it doesn't wait for previous task to be terminated. Hence using `resyncExecutor.scheduleWithFixedDelay` instead. + Minor changes in ControllerTest regarding resync expectations/wait time
The
resync
task inkubernetes-client/src/main/java/io/fabric8/kubernetes/client/informers/cache/Controller.java
is currently submitted into theresyncExecutor
with ascheduleAtFixedRate
.The
scheduleAtFixedRate
ofServiceExecutor
does not wait for a previous task to be terminated to run the next one.If the resync tasks takes too long, that may make the Controller to restart the resync quickly. In recent kubernetes versions the requests can then be throttled which may cascade other issues.
By replacing it with
scheduleWithFixedDelay
, we can be sure too have a reasonnable delay between syncs.The text was updated successfully, but these errors were encountered: