Builds failing because of apparently unreachable API sites

Description

Both the v11 and v7 stack builds have been failing a lot recently because of problems reaching the following API link URLs:

  • http://logback.qos.ch/apidocs

  • https://www.slf4j.org/apidocs

These failures appear to be rejected connections by the server, rather than a routing problem.

It is worth noting that they both appear to be served by the same host: both of those FQDNs are CNAMEs for a entry with a similar name (e.g., ge.slf4j.org) with an A record of 83.166.144.67 and an AAAA record of 2001:1600:4:8:f816:3eff:fe05:5faf.

The failure condition is observable in a browser while it's present, but it appears to be intermittent. Today, for example, the site was broken from before 8am to around 11am UK local.

Interestingly, although I could see the error in a browser or using curl, I wasn't able to reproduce what the Jenkins run saw, which was this:

For me, the build completed but without links to the problematic APIs appearing in the output. That's obviously annoying but better for the purposes of the nightly builds.

At the moment, I can't account for the difference in behaviour. The only things I can see that might be different are:

  • On my side, Mac; on the Jenkins box, Linux.

  • On my side, Corretto 11.0.4; on the Jenkins box, Corretto 11.0.3.

  • My machine has no IPv6 connectivity, not sure whether the Jenkins box does.

Environment

None

Activity

Show:

Ian Young July 25, 2019 at 3:44 PM

This specific issue appears to have been resolved. and cover the more general issue.

Ian Young July 19, 2019 at 4:13 PM

I got mail back from Ceki Gulcu saying that he thinks the issue should now be resolved. I'll review after tonight's nightly runs; if we still have problems I will pull these links from the javadoc plugin's configuration in the parent POM.

Ian Young July 18, 2019 at 4:27 PM

There are several possible routes forward. The least-effort one for us is of course that if these sites become reliable for us again, we can just ignore the issue for the next time.

Second option would be migrating from the original sites to javadoc.io as discussed in JPAR-140. I've spent a bit of time trying to get this working but haven't had much luck so far. It looks promising in principle, but as mentioned in that issue that's only true as long as that site is itself sufficiently reliable.

Third option would be a bit of a shot in the dark, which is that the rolling mess involved with upgrading the JDK and Maven javadoc plugin may actually move us into a zone where these failures are ignored again — which seems to be what's happening on my machine, although I still have to confirm that. We'll need to try that anyway as part of as we now have a new set of components to test.

Last option would be to just remove the links to these particular APIs from the parent POM. Although that's not going to cause a huge problem in this specific case (because we don't use these APIs in such a way that we really must have proper links in the Javadoc) I'd still like a more general solution. That's why I'm not going for just stripping those now, although I think I will need to do that if we don't see a resolution in the next few days. Potentially something to discuss in Friday's meeting.

Ian Young July 18, 2019 at 10:47 AM

Same issues observed with the mailing lists and JIRA for the projects.

I have sent the project leader mail to find out whether he's already aware of this.

Ian Young July 18, 2019 at 10:33 AM

Although these appear to be the same host, there are times when one of the URLs results in an error while the other functions:

Note also that when it does work, the logback URL causes a redirect:

We probably need to fix that up, not that it will help in this case.

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Created July 18, 2019 at 10:18 AM
Updated January 18, 2023 at 1:09 PM
Resolved July 25, 2019 at 3:44 PM