Skip to content

applying backoff for rate-limited Maven downloads #100

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

Closed

Conversation

ghost
Copy link

@ghost ghost commented May 10, 2019

Issue #, if available: #99

Description of changes:
When a 429 response is received when attempting to download one of the jars, this will apply exponential backoff, sleeping anywhere between 1 second (on the first retry) to 16 (on the final retry).

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@rk-yen
Copy link

rk-yen commented May 11, 2019

👍

try:
return urlopen(url)
except HTTPError as e:
if e.code == 429:
Copy link

@whummer whummer Aug 1, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jtfalkenstein Can we change this to perform retries also for other error codes?

It seems that Maven is not consistently using 429, but also other error codes. Recently, we've seen 502 (or 504) errors returned from the gateway, but these errors appear to be related to client request throttling.

Including other error codes here would make the installation much more resilient. Thanks

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weird. You know, we've been running this install via an automated Jenkins build a lot and haven't encountered anything other than a 429.

I'm inclined to do as you request on this, but I do have a concern on this... Any time we repeatedly pound a server with requests that we're getting error responses for, we risk being blacklisted by the server admins.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point. Good to know that you haven't had any issues recently with the 429 fix. Merging this PR as-is would already be a huge improvement over the status quo. :) Thanks

@ghost
Copy link
Author

ghost commented Aug 1, 2019

@pfifer, what are the chances of this thing getting merged?

@Gr1N
Copy link

Gr1N commented Aug 2, 2019

Hi! Any progress on PR?

@whummer
Copy link

whummer commented Mar 8, 2020

+1 - would be great to get this merged! @pfifer @rk-yen @jtfalkenstein

@ghost
Copy link
Author

ghost commented Mar 8, 2020

I just want to note that this code had been working flawlessly for us for almost a year of daily use.

@whummer
Copy link

whummer commented Oct 7, 2020

Bumping this PR one more time @pfifer @rk-yen @jtfalkenstein

I just want to note that this code had been working flawlessly for us for almost a year of daily use.

Same here - this fix has been working flawlessly for us for a long period of time now. Any chance we can get this merged, so we don't have to depend on our own fork of this library? Thanks!

@lieutdan13
Copy link

+1 on this fix

@@ -50,7 +54,7 @@

PACKAGE_NAME = 'amazon_kclpy'
JAR_DIRECTORY = os.path.join(PACKAGE_NAME, 'jars')
PACKAGE_VERSION = '2.0.1'
PACKAGE_VERSION = '2.0.5'

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the current version is 2.0.1, should this be changed to 2.0.2?

@@ -17,16 +17,20 @@

import os
import shutil
from time import sleep

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like they have the imports organized a bit differently. Perhaps keep "import x" at the top and move the "from x import y" in the next section...all alphabetically, of course.

@lieutdan13
Copy link

Who do we need to tag to get this merged?

@ghost
Copy link
Author

ghost commented Aug 10, 2021

I'm gong to close this PR in favor of #141, since I cannot update the repository any longer now that I'm not at that company. On that new pull request, I've fixed the above-mentioned version change and am more consistent about imports.

@ghost ghost closed this Aug 10, 2021
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants