-
Notifications
You must be signed in to change notification settings - Fork 127
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
[MRESOLVER-396] Back off on too many requests #326
Conversation
Provide a way to "back off", and lower the request pace if remote claims "too many requests" --- https://issues.apache.org/jira/projects/MRESOLVER/issues/MRESOLVER-396
maven-resolver-api/src/main/java/org/eclipse/aether/ConfigurationProperties.java
Show resolved
Hide resolved
...resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java
Outdated
Show resolved
Hide resolved
* exponential backoff * Retry-After header * Maximum of retryInterval, when request should be rather failed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just minor remarks about documentation
src/site/markdown/configuration.md
Outdated
@@ -43,8 +43,11 @@ Option | Type | Description | Default Value | Supports Repo ID Suffix | |||
`aether.connector.http.preemptiveAuth` | boolean | Should HTTP client use preemptive-authentication for all HTTP verbs (works only w/ BASIC). By default is disabled, as it is considered less secure. | `false` | yes | |||
`aether.connector.http.preemptivePutAuth` | boolean | Should HTTP client use preemptive-authentication for HTTP PUTs only (works only w/ BASIC). By default is enabled (same as Wagon). | `true` | yes | |||
`aether.connector.http.retryHandler.count` | int | The maximum number of times a request to a remote HTTP server should be retried in case of an error. | `3` | yes | |||
`aether.connector.http.retryHandler.interval` | long | The initial retry interval if server responds with "too many requests". Is multiplied by 1, 2,.. on each try. | `5000` | yes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`aether.connector.http.retryHandler.interval` | long | The initial retry interval if server responds with "too many requests". Is multiplied by 1, 2,.. on each try. | `5000` | yes | |
`aether.connector.http.retryHandler.interval` | long | The initial retry interval if server responds with "too many requests". Previous value is multiplied by 2 on each retry. | `5000` | yes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, is not, initial value is multiplied with 1, 2, 3...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn’t this what my suggestion says as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think not, you proposed "exponential", where you have some sort of loop like this:
retryInterval = initial
loop:
retryInterval = retryInterval * counter
For input 1, 2, 3 and initial=5000 this produces 5000, 10000, 30000
What I did is slightly different:
retryInterval;
loop:
retryInterval = initial * counter
For input 1,2,3 and initial=5000 this produces 5000, 10000, 15000 etc
IMHO, "real exponential" does not really make sense here: your build is time sensitive, if you are forced to wait (exponentially) for server as it is overloaded, then its better to make your IT env/vendor fix it 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, you are right. Let's leave it like you proposed.
...resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, though a comment to explain the usage of the ThreadLocal
would be welcomed imho.
Provide a way to "back off", and lower the request pace if remote claims "too many requests"
https://issues.apache.org/jira/projects/MRESOLVER/issues/MRESOLVER-396