Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] The Eclipse IDE 2019-12 release is available now!


It's no doubt currently not helping the server's performance that the download.php query appears to know about so few mirrors for yesterday's release:

Bug is open with more details for this additional problem.

Meanwhile the other problem continues:

$curl -I
  % Total    % Received % Xferd  Average Speed   Time    Time Time  Current
                                 Dload  Upload   Total   Spent Left  Speed
  0   425    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0HTTP/1.1 200 OK
Server: nginx
Date: Thu, 19 Dec 2019 12:43:53 GMT
Content-Type: application/x-java-archive
Content-Length: 425
Connection: keep-alive
Last-Modified: Fri, 06 Dec 2019 14:51:18 GMT
ETag: "1a9-5990a2db16a89"
X-NodeID: download1
X-Proxy-Cache: STALE
Accept-Ranges: bytes

It appears we need to wait for Canada to wake up. :-(


On 19.12.2019 10:56, Ed Merks wrote:

Of course no great release is complete without an awesome new glitch.  For the 2019-06 release, transparently redirected to so loading

would serve up

That wasn't a good thing.  The transparent redirection behavior (including transparent redirection to mirrors) has since been disabled for a number of additional reasons.

For the 2019-12 release, a HEAD request to return stale information. I.e., the following code:

    URL url = new URL("";);     HttpURLConnection openConnection = (HttpURLConnection)url.openConnection();
    int responseCode = openConnection.getResponseCode();
    System.err.println("url=" + url + " response=" + responseCode + " lastModified=" + openConnection.getLastModified() + " contentLength="
        + openConnection.getContentLength());

prints the following result:

url= response=200 lastModified=1575643878000 contentLength=425

Unfortunately, p2 and the Eclipse Installer's infrastructure rely on proper/correct server responses.  The net effect of this incorrect response is to indicate that it's valid to use a locally cached version of compositeContent.jar, if it exists, which will find only M2, M3, and RC1, which still exist on the server.  I don't know if this will make installs fail or if it will make installs install RC1 instead of R, but clearly both are very bad. The average typical user will likely not have loaded before, so for those it won't be a problem.  But for those with a cache, this will be a problem.

I've opened to track this problem.  It needs to be fixed ASAP.  Furthermore, I hope that the problem is not fixed simply by manually flushing some cache because we don't want to see this problem ever again. This resource was deleted 19 hours ago and the server, in general, needs to return a 404 for HEAD/GET requests as soon as possible after any resource has been removed.


On 18.12.2019 16:00, Frederic Gurr wrote:
The main repository is at

( also points to it)

The EPP (all-in-one) packages are available at

The landing page can be found here:

Thanks to all users, bug reporters, contributors, committers, releng
engineers and everyone else involved with making this release possible!

Happy Holidays!



Back to the top