Add some resiliency to the collection of reachability metadata #592
Comments
|
Are you using a custom repository URL? The default should be to pick the release in Maven Central. I'm not sure that increasing the connect timeout would be helpful in general, but retries with exponential backoff may be. |
|
Thanks for taking a look, @melix. We're using the default repository. |
|
Right, it's quite curious, because in this case the repository should be resolved as a Maven artifact. I don't think we'd have the ability to retry in this case. Also it would be strange that this particular dependency fails but not the regular dependency resolution. Unless if you are using mirrors? |
|
No mirrors involved. The builds are running on GitHub Actions and use Maven Central for the vast majority of their dependencies, with a little bit of https://repo.spring.io mixed in when we're testing snapshots. |
|
Sorry, I may not have been entirely accurate in my earlier comment about the repository URL. Looking at the code in |
|
Ah thanks, that makes more sense to me, then you're probably hitting rate limiting from GitHub APIs, we've seen this (in another context) for Micronaut builds too. Something you might want to consider is actually to download the repository zip file and include it in your sources, then configure the extension to point to it. Not sure how much this is an option for you. |
|
AFAIK, GitHub doesn't rate-limit download links. When it does rate limit, from what I have seen it's done with a 403 response rather than by refusing a connection. Experimenting with curl, https://github.com/oracle/graalvm-reachability-metadata/releases/download/0.3.7/graalvm-reachability-metadata-0.3.7.zip redirects to
It's certainly an option. Thanks for the suggestion. That said, I think an improvement here would be better as it would have broader benefit. I am happy to contribute something if we can agree on the details (number of retries, back off approach, etc). |
|
Sure, we will implement retries in case we don't download from Central, my suggestion was a workaround in the meantime. |
Is your feature request related to a problem? Please describe.
We build 10s of native images on a nightly basis and roughly one night in three (at the time of writing) we'll see a failure due to a connection timeout when downloading reachability metadata. I would like our builds to be more robust.
Describe the solution you'd like
Builds could be made more robust by configuring a longer connection timeout or by retrying failures that should be transient.
Describe alternatives you've considered
I considered some configuration on the Gradle side to retry the task that's failing. Some research suggests that this isn't something that Gradle offers, at least not without resorting to hacks. It also wouldn't benefit other users of
GraalVMReachabilityMetadataService.Additional context
Connection timeout stack trace
The text was updated successfully, but these errors were encountered: