Inconsistent 404s for some URLs?

[mikehearn]

Inconsistent 404s for some URLs?

[karianna]

Might be a region thing or a VPN thing?

[mikehearn]

Maybe a region thing - that's what I was asking with inconsistent shards. I don't think this customer uses VPNs (and if they did, why would it matter?)

[karianna]

Maybe a region thing - that's what I was asking with inconsistent shards. I don't think this customer uses VPNs (and if they did, why would it matter?)

VPN might mean they're appearing to come from a different region (e.g., one that we're having challenges with on a given day)

[mikehearn]

Is there a way to download the dataset in bulk and serve it myself as a fallback?

[karianna]

Is there a way to download the dataset in bulk and serve it myself as a fallback?

https://api.adoptium.net/q/swagger-ui/#/ has all of the API options, you might be able to script a wrapper around some of that?

[tellison]

@mikehearn I see in your log:
wget https://api.adoptopenjdk.net/v3/binary/latest/22/ga/windows/x64/jdk/hotspot/normal/adoptopenjdk

While we do have redirects in place, the old AdoptOpenJDK API is deprecated and you should preferably be going directly to api.adoptium.net, i.e.

https://api.adoptium.net/v3/binary/latest/22/ga/windows/x64/jdk/hotspot/normal/eclipse

In reality, I suspect that redirect is not causing the problem your user is experiencing. I also cannot reproduce the problem and agree that there is possibly an intermediary causing the 404.

[mikehearn]

Is the only difference the domain name? If so then it should be easy enough to update.

[karianna]

Is the only difference the domain name? If so then it should be easy enough to update.

There are some subtle differences, but I'd start with that and see what falls out.

[mikehearn]

Could someone with sufficient access please do a consistency check on the replicas? @ennerf is still seeing problems but only when accessing the service from Austria. Accessed from the USA it works. So there's definitely some buggy replication going on here, and it's not fixing itself.

[johnoliver]

This should be resolved as we have merged a fix in #1053 but in general the adoptium api was working in all regions at:

https://api.adoptium.net/v3/binary/latest/22/ga/windows/x64/jdk/hotspot/normal/eclipse

and it was purely an api.adoptopenjdk.net issue. api.adoptopenjdk.net is deprecated, so even going forward you should migrate.

[karianna]

Closing now that #1053 has landed.

[mikehearn]

Thanks.

[mikehearn]

If I understand correctly, there is no documentation or any other guidance on how to migrate from one domain name to the other? I just tried to do it and I'm getting a 404 for:

https://api.adoptium.net/v3/binary/latest/17/ga/mac/x64/jdk/hotspot/normal/adoptopenjdk

It's unclear why, as the URL appears to have the same form as the example given above. api.adoptopenjdk.net works just fine. The README states only that the old API is deprecated due to a rebrand, so the fact that it appears to have a different backend and gives different answers is a surprise.

This is a great service that's very useful to the JVM community, but I have to say, if you want people to do new work for some obscure reason (what was wrong with the old name anyway), it would really help to have some tutorial on how to migrate. Neither the API website nor the README give any hint of differences but there must be some!

[karianna]

https://api.adoptium.net will take you to the swagger UI definition, that should give you what the new target URL should be, in your case it should be https://api.adoptium.net/v3/binary/latest/17/ga/mac/x64/jdk/hotspot/normal/eclipse (adoptopenjdk was renamed for legal reasons) - point taken on migration in the future.