Added wait and retries for rate limit response code from Bitbucket server #433
Conversation
|
This is a really handy improvement that would be beneficial for everyone. |
|
@bitwiseman , are you in charge of merging PRs? The rate API is quite important to be fixed especially in large organizations… |
|
If you have many open prs, #445 might be important for you as well, on our setup it reduced the number of api calls massively |
| LOGGER.fine("Bitbucket API rate limit reached, sleeping for 5 sec then retry..."); | ||
| try { | ||
| Thread.sleep(API_RATE_LIMIT_WAIT_TIME_DEFAULT); | ||
| } catch (InterruptedException e) { | ||
| // TODO Auto-generated catch block | ||
| e.printStackTrace(); | ||
| } |
There was a problem hiding this comment.
These two blocks are identical, convert to a method.
| } else if (API_RATE_LIMIT_CODE == status) { | ||
| LOGGER.fine("Bitbucket API rate limit reached, sleeping for 5 sec then retry..."); | ||
| try { | ||
| Thread.sleep(API_RATE_LIMIT_WAIT_TIME_DEFAULT); |
There was a problem hiding this comment.
Just waiting for 5 seconds will cause a lot of polling and spamming of the server. Please shift to some kind of progressive back off where each of retry waits longer (up to some reasonable limit.
Alternative: see if they the headers of the 429 provide information about when to the limit will reset and sleep for something like that long.
|
See #414 |
|
Can we get some progress on this? I'm constantly hitting 429 on our Jenkins setup and we definitely welcome this rate limit progressive back off strategy. |
|
Investigation was done here: #414 (comment) - there is unfortunately no headers we can use. Any chance @shankarinece you can have a last look at the comments? E.g. some type of exponential back-off? |
|
Closing in favor of #581 |
Added 5 seconds wait and retry the same API if Bitbucket responds with rate-limit response code (429). Relates to JENKINS-62479,
Your checklist for this pull request