TT-7248 Added backoff algorithm to pull the plugin bundles. #4513
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
API tests result: success ✅ |
💥 CI tests failed 🙈git-stateall okPlease look at the run or in the Checks tab. |
|
API tests result: success ✅ |
sredxny
changed the title
💥 CI tests failed 🙈git-statediff --git a/gateway/coprocess_bundle_test.go b/gateway/coprocess_bundle_test.go
index 53f65df..a82dfe1 100644
--- a/gateway/coprocess_bundle_test.go
+++ b/gateway/coprocess_bundle_test.go
@@ -11,9 +11,10 @@ import (
"runtime"
"testing"
+ "github.com/stretchr/testify/assert"
+
"github.com/TykTechnologies/tyk/config"
"github.com/TykTechnologies/tyk/test"
- "github.com/stretchr/testify/assert"
)
var (
Please look at the run or in the Checks tab. |
|
API tests result: success ✅ |
|
API tests result: success ✅ |
💥 CI tests failed 🙈git-statediff --git a/gateway/coprocess_bundle_test.go b/gateway/coprocess_bundle_test.go
index 53f65df..a82dfe1 100644
--- a/gateway/coprocess_bundle_test.go
+++ b/gateway/coprocess_bundle_test.go
@@ -11,9 +11,10 @@ import (
"runtime"
"testing"
+ "github.com/stretchr/testify/assert"
+
"github.com/TykTechnologies/tyk/config"
"github.com/TykTechnologies/tyk/test"
- "github.com/stretchr/testify/assert"
)
var (
Please look at the run or in the Checks tab. |
|
API tests result: success ✅ |
sredxny
commented
Dec 12, 2022
gateway/api_definition.go
Outdated
Comment on lines
628
to
629
| if def.CustomMiddlewareBundle != "" { | ||
| wg.Add(1) |
There was a problem hiding this comment.
@lonelycode do you think we need this or just handle all the apis in the same way? The reason to do it in this way is to avoid the gateway to spawn a lot of goroutines, and instead only create an async job when the api to be loaded need to pull a bundle
gateway/api_definition.go
Outdated
| func (a APIDefinitionLoader) prepareSpecs(apiDefs []nestedApiDefinition) []*APISpec { | ||
| var specs []*APISpec | ||
|
|
||
| var wg sync.WaitGroup |
There was a problem hiding this comment.
@buger I have something against waitgroups and it's that it can generate a lot of jobs at the same time without a limit. What about if we use a pool of workers? in this case, how many of them we should have? or it's too complex for this problem?
There was a problem hiding this comment.
There was a problem hiding this comment.
@titpetric awesome, that leads me to the questions: how many should load at the same time?
sredxny
changed the title
|
Kudos, SonarCloud Quality Gate passed! |
|
API tests result: success ✅ |
sredxny
deleted the
feature/TT-7248-implement-backoff-for-plugin-bundle-retry
branch
|
/release to release-4 |
|
Working on it! Note that it can take a few minutes. |
Merged
7 tasks
|
@sredxny Succesfully merged PR |
tykbot bot
pushed a commit
that referenced
this pull request
Dec 13, 2022
<!-- Provide a general summary of your changes in the Title above --> ## Description Currently if the gateway cannot pull a plugin bundle then it just throw error and continue processing the next api definition. In this PR was introduced a new behavior, the gateway will attempt to download the bundle, of it fails then it will try until 4 more times, the timeframe between one attempt and the other is defined by an exponential backoff described [here](https://pkg.go.dev/github.com/cenkalti/backoff#NewExponentialBackOff) ~~Now when an API will load a bundle, it's processed async so the loading of the other apis is not blocked by this one.~~ ## Related Issue https://tyktech.atlassian.net/browse/TT-7248 ## Motivation and Context Provide a better response when downloading the bundles fails for external causes ## How This Has Been Tested - Added unit test for backoff algorithm - in Dash+GW setup: created apis, one of them with bundle plugin...finally check that all the apis are reachable ## Screenshots (if appropriate) ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality) ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply --> <!-- If there are no documentation updates required, mark the item as checked. --> <!-- Raise up any additional concerns not covered by the checklist. --> - [ ] I ensured that the documentation is up to date - [ ] I explained why this PR updates go.mod in detail with reasoning why it's required - [ ] I would like a code coverage CI quality gate exception and have explained why (cherry picked from commit 2230b14)
|
/release to release-4-lts |
|
Working on it! Note that it can take a few minutes. |
Closed
7 tasks
tykbot bot
pushed a commit
that referenced
this pull request
Dec 13, 2022
<!-- Provide a general summary of your changes in the Title above --> Currently if the gateway cannot pull a plugin bundle then it just throw error and continue processing the next api definition. In this PR was introduced a new behavior, the gateway will attempt to download the bundle, of it fails then it will try until 4 more times, the timeframe between one attempt and the other is defined by an exponential backoff described [here](https://pkg.go.dev/github.com/cenkalti/backoff#NewExponentialBackOff) ~~Now when an API will load a bundle, it's processed async so the loading of the other apis is not blocked by this one.~~ https://tyktech.atlassian.net/browse/TT-7248 Provide a better response when downloading the bundles fails for external causes - Added unit test for backoff algorithm - in Dash+GW setup: created apis, one of them with bundle plugin...finally check that all the apis are reachable <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality) <!-- Go over all the following points, and put an `x` in all the boxes that apply --> <!-- If there are no documentation updates required, mark the item as checked. --> <!-- Raise up any additional concerns not covered by the checklist. --> - [ ] I ensured that the documentation is up to date - [ ] I explained why this PR updates go.mod in detail with reasoning why it's required - [ ] I would like a code coverage CI quality gate exception and have explained why (cherry picked from commit 2230b14)
|
@sredxny Succesfully merged PR |
|
/release to release-4.3 |
|
API tests result: success ✅ DescriptionCurrently if the gateway cannot pull a plugin bundle then it just throw
Related Issuehttps://tyktech.atlassian.net/browse/TT-7248 Motivation and ContextProvide a better response when downloading the bundles fails for How This Has Been Tested
Screenshots (if appropriate)Types of changes
Checklist
|
|
/release to release-4.3 |
|
Working on it! Note that it can take a few minutes. |
Merged
7 tasks
|
@sredxny Succesfully merged PR |
tykbot bot
pushed a commit
that referenced
this pull request
Dec 13, 2022
<!-- Provide a general summary of your changes in the Title above --> ## Description Currently if the gateway cannot pull a plugin bundle then it just throw error and continue processing the next api definition. In this PR was introduced a new behavior, the gateway will attempt to download the bundle, of it fails then it will try until 4 more times, the timeframe between one attempt and the other is defined by an exponential backoff described [here](https://pkg.go.dev/github.com/cenkalti/backoff#NewExponentialBackOff) ~~Now when an API will load a bundle, it's processed async so the loading of the other apis is not blocked by this one.~~ ## Related Issue https://tyktech.atlassian.net/browse/TT-7248 ## Motivation and Context Provide a better response when downloading the bundles fails for external causes ## How This Has Been Tested - Added unit test for backoff algorithm - in Dash+GW setup: created apis, one of them with bundle plugin...finally check that all the apis are reachable ## Screenshots (if appropriate) ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality) ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply --> <!-- If there are no documentation updates required, mark the item as checked. --> <!-- Raise up any additional concerns not covered by the checklist. --> - [ ] I ensured that the documentation is up to date - [ ] I explained why this PR updates go.mod in detail with reasoning why it's required - [ ] I would like a code coverage CI quality gate exception and have explained why (cherry picked from commit 2230b14)
sredxny
added a commit
that referenced
this pull request
Dec 13, 2022
…lugin bundles. (#4513) (#4531) TT-7248 Added backoff algorithm to pull the plugin bundles. (#4513) <!-- Provide a general summary of your changes in the Title above --> ## Description Currently if the gateway cannot pull a plugin bundle then it just throw error and continue processing the next api definition. In this PR was introduced a new behavior, the gateway will attempt to download the bundle, of it fails then it will try until 4 more times, the timeframe between one attempt and the other is defined by an exponential backoff described [here](https://pkg.go.dev/github.com/cenkalti/backoff#NewExponentialBackOff) ~~Now when an API will load a bundle, it's processed async so the loading of the other apis is not blocked by this one.~~ ## Related Issue https://tyktech.atlassian.net/browse/TT-7248 ## Motivation and Context Provide a better response when downloading the bundles fails for external causes ## How This Has Been Tested - Added unit test for backoff algorithm - in Dash+GW setup: created apis, one of them with bundle plugin...finally check that all the apis are reachable ## Screenshots (if appropriate) ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality) ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply --> <!-- If there are no documentation updates required, mark the item as checked. --> <!-- Raise up any additional concerns not covered by the checklist. --> - [ ] I ensured that the documentation is up to date - [ ] I explained why this PR updates go.mod in detail with reasoning why it's required - [ ] I would like a code coverage CI quality gate exception and have explained why Co-authored-by: Sredny M <sredny.buitrago@gmail.com>
sredxny
added a commit
that referenced
this pull request
Dec 13, 2022
…gin bundles. (#4513) (#4529) TT-7248 Added backoff algorithm to pull the plugin bundles. (#4513) <!-- Provide a general summary of your changes in the Title above --> ## Description Currently if the gateway cannot pull a plugin bundle then it just throw error and continue processing the next api definition. In this PR was introduced a new behavior, the gateway will attempt to download the bundle, of it fails then it will try until 4 more times, the timeframe between one attempt and the other is defined by an exponential backoff described [here](https://pkg.go.dev/github.com/cenkalti/backoff#NewExponentialBackOff) ~~Now when an API will load a bundle, it's processed async so the loading of the other apis is not blocked by this one.~~ ## Related Issue https://tyktech.atlassian.net/browse/TT-7248 ## Motivation and Context Provide a better response when downloading the bundles fails for external causes ## How This Has Been Tested - Added unit test for backoff algorithm - in Dash+GW setup: created apis, one of them with bundle plugin...finally check that all the apis are reachable ## Screenshots (if appropriate) ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality) ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply --> <!-- If there are no documentation updates required, mark the item as checked. --> <!-- Raise up any additional concerns not covered by the checklist. --> - [ ] I ensured that the documentation is up to date - [ ] I explained why this PR updates go.mod in detail with reasoning why it's required - [ ] I would like a code coverage CI quality gate exception and have explained why Co-authored-by: Sredny M <sredny.buitrago@gmail.com>
|
/release to release-4-lts |
|
Working on it! Note that it can take a few minutes. |
Merged
7 tasks
tykbot bot
pushed a commit
that referenced
this pull request
Dec 14, 2022
<!-- Provide a general summary of your changes in the Title above --> Currently if the gateway cannot pull a plugin bundle then it just throw error and continue processing the next api definition. In this PR was introduced a new behavior, the gateway will attempt to download the bundle, of it fails then it will try until 4 more times, the timeframe between one attempt and the other is defined by an exponential backoff described [here](https://pkg.go.dev/github.com/cenkalti/backoff#NewExponentialBackOff) ~~Now when an API will load a bundle, it's processed async so the loading of the other apis is not blocked by this one.~~ https://tyktech.atlassian.net/browse/TT-7248 Provide a better response when downloading the bundles fails for external causes - Added unit test for backoff algorithm - in Dash+GW setup: created apis, one of them with bundle plugin...finally check that all the apis are reachable <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality) <!-- Go over all the following points, and put an `x` in all the boxes that apply --> <!-- If there are no documentation updates required, mark the item as checked. --> <!-- Raise up any additional concerns not covered by the checklist. --> - [ ] I ensured that the documentation is up to date - [ ] I explained why this PR updates go.mod in detail with reasoning why it's required - [ ] I would like a code coverage CI quality gate exception and have explained why (cherry picked from commit 2230b14)
|
@sredxny Succesfully merged PR |
sredxny
added a commit
that referenced
this pull request
Dec 14, 2022
… plugin bundles. (#4513) (#4537) TT-7248 Added backoff algorithm to pull the plugin bundles. (#4513) <!-- Provide a general summary of your changes in the Title above --> ## Description Currently if the gateway cannot pull a plugin bundle then it just throw error and continue processing the next api definition. In this PR was introduced a new behavior, the gateway will attempt to download the bundle, of it fails then it will try until 4 more times, the timeframe between one attempt and the other is defined by an exponential backoff described [here](https://pkg.go.dev/github.com/cenkalti/backoff#NewExponentialBackOff) ~~Now when an API will load a bundle, it's processed async so the loading of the other apis is not blocked by this one.~~ ## Related Issue https://tyktech.atlassian.net/browse/TT-7248 ## Motivation and Context Provide a better response when downloading the bundles fails for external causes ## How This Has Been Tested - Added unit test for backoff algorithm - in Dash+GW setup: created apis, one of them with bundle plugin...finally check that all the apis are reachable ## Screenshots (if appropriate) ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality) ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply --> <!-- If there are no documentation updates required, mark the item as checked. --> <!-- Raise up any additional concerns not covered by the checklist. --> - [ ] I ensured that the documentation is up to date - [ ] I explained why this PR updates go.mod in detail with reasoning why it's required - [ ] I would like a code coverage CI quality gate exception and have explained why Co-authored-by: Sredny M <sredny.buitrago@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
Currently if the gateway cannot pull a plugin bundle then it just throw error and continue processing the next api definition. In this PR was introduced a new behavior, the gateway will attempt to download the bundle, of it fails then it will try until 4 more times, the timeframe between one attempt and the other is defined by an exponential backoff described here
Now when an API will load a bundle, it's processed async so the loading of the other apis is not blocked by this one.Related Issue
https://tyktech.atlassian.net/browse/TT-7248
Motivation and Context
Provide a better response when downloading the bundles fails for external causes
How This Has Been Tested
Screenshots (if appropriate)
Types of changes
Checklist