Implement exponential backoff for SB operations (CC v3 API) #2667
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thanks for contributing to cloud_controller_ng. To speed up the process of reviewing your pull request please provide us with:
A short explanation of the proposed change:
Introduce a new parameter
broker_client_async_poll_exponential_backoff_rate
which lets users configure exponential backoff for service related polling jobs. This includes the creation, update and deletion of service instances and the creation and deletion of service credential bindings.An explanation of the use cases your change solves
The CC already offers two parameters with which the polling interval
broker_client_default_async_poll_interval_seconds
and the polling durationbroker_client_max_async_poll_duration_minutes
can be configured. Though, this is not enough to prevent that the CC can be overloaded by a single user e.g. by creating many service instances, while the broker needs a lot of time to handle the request. This will result in many polling jobs, which overload the worker processes.The newly introduced parameter
broker_client_async_poll_exponential_backoff_rate
, by default, does not change the current behaviour as it is set to 1.0, which means there is no exponential backoff. When set to a higher number, the time until each re-enqueued job will be run will increase and therefore lead to much less polling jobs, which need to be run by the worker processes.I have reviewed the contributing guide
I have viewed, signed, and submitted the Contributor License Agreement
I have made this pull request to the
main
branchI have run all the unit tests using
bundle exec rake
I have run CF Acceptance Tests