I am looking at this now to see if I can understand.
Denis/Webmaster if you can help that would be great as I don't
understand how different clients are getting different
responses.
$curl -I
http://download.eclipse.org/technology/epp/packages/2020-03/compositeContent.jar
% Total % Received % Xferd Average Speed Time
Time Time Current
Dload Upload Total
Spent Left Speed
0 429 0 0 0 0 0 0 --:--:--
--:--:-- --:--:-- 0HTTP/1.1 200 OK
Server: nginx
Date: Wed, 18 Mar 2020 13:06:13 GMT
Content-Type: application/x-java-archive
Content-Length: 429
Connection: keep-alive
Last-Modified: Fri, 06 Mar 2020 14:22:22 GMT
ETag: "1ad-5a03061c70fb5"
X-NodeID: download2
X-Proxy-Cache: STALE
Accept-Ranges: bytes
When I do this it bypasses the cache:
$curl -I --header "X-Cache-Bypass: true"
http://download.eclipse.org/technology/epp/packages/2020-03/compositeContent.jar
% Total % Received % Xferd Average Speed Time
Time Time Current
Dload Upload Total
Spent Left Speed
0 0 0 0 0 0 0 0 --:--:--
--:--:-- --:--:-- 0HTTP/1.1 404 Not Found
Server: nginx
Date: Wed, 18 Mar 2020 13:09:15 GMT
Content-Type: text/html
Connection: keep-alive
Vary: Accept-Encoding
X-NodeID: download2
But a subsequent call still returns it as existing so it
does not flush the cache:
$curl -I
http://download.eclipse.org/technology/epp/packages/2020-03/compositeContent.jar
% Total % Received % Xferd Average Speed Time
Time Time Current
Dload Upload Total
Spent Left Speed
0 429 0 0 0 0 0 0 --:--:--
--:--:-- --:--:-- 0HTTP/1.1 200 OK
Server: nginx
Date: Wed, 18 Mar 2020 13:09:21 GMT
Content-Type: application/x-java-archive
Content-Length: 429
Connection: keep-alive
Last-Modified: Fri, 06 Mar 2020 14:22:22 GMT
ETag: "1ad-5a03061c70fb5"
X-NodeID: download2
X-Proxy-Cache: STALE
Accept-Ranges: bytes
Both compositeContent.jar and compositeArtifacts.jar need
to yield 404 for a HEAD request...
Note how it says "X-Proxy-Cache: STALE" in each case.
Several calls like this:
$curl -I http://download.eclipse.org/technology/epp/packages/2020-03/content.jar
% Total % Received % Xferd Average Speed Time
Time Time Current
Dload Upload Total
Spent Left Speed
0 77058 0 0 0 0 0 0 --:--:--
--:--:-- --:--:-- 0HTTP/1.1 200 OK
Server: nginx
Date: Wed, 18 Mar 2020 13:15:15 GMT
Content-Type: application/x-java-archive
Content-Length: 77058
Connection: keep-alive
Last-Modified: Tue, 17 Mar 2020 11:19:04 GMT
ETag: "12d02-5a10b1a79ee91"
X-NodeID: download2
X-Proxy-Cache: HIT
Accept-Ranges: bytes
Show "X-Proxy-Cache: HIT".
I think both those files were deleted two hours ago.
Regards,
Ed
On 18.03.2020 13:22, Jonah Graham wrote:
I believe everything is now in place for
the release except that I and CI user cannot
touch the directory so that mirrors are working for p2.
See Bug 561215
For completeness... Ed's
assessment of file timestamps vs. directory is
spot on, since p2 typically uses the directory
as the mirrorsURL parameter.
Denis
On 2020-03-17 1:20 a.m., Ed Merks wrote:
Markus,
I believe that the server's general approach
via download.php is to consider the time stamp
of the local file versus its timestamp on the
mirror. If they match, the mirror is a good one
and will be returned in the list. For the
download folder, I expect the timestamp is not
so important because only individual files will
be downloaded from it. E.g., for this link, the
timestamp of the file is important, but not the
timestamps of any of the parent folders:
And here the timestamp of the 2020-03 folder
itself is definitely important.
That all being said, an install will only need
to download 4 artifacts from the EPP repo, while
needing to download 100s from the train repo, so
if there were no mirrors for the EPP repo, it
would not cause such a huge problem as it does
when there are no mirrors for the train repo.
That repo already exists and has many mirrors:
You are right. I used to be very careful
with the modification times of files and
directories, especially the download
directories are important. I got used to
using my TIMESTAMP files that can be found
here and there on the download server,
usually in commands like
touch -r . TIMESTAMP
touch -r TIMESTAMP .
to "store" the modification times of the
current working directory, and to use it
afterwards to copy the very same
modification time back to it.
Of course it's not clear over which
time period that happened, but there's
always quite a bit of activity the day
of and the days after... The mirror
failures right after the most 2019-12
release certainly brought that
download server to its knees enough to
take note that there was an ongoing
problem. And that's in December,
close to Christmas time, when you
wouldn't expect quite so much either.
That's all to say that I very much
appreciate Jonah being conservative on
this front.
Note too that I see that the mirrors
are back now!
Now that I'm thinking about it
though, we should be careful what
happens to the timestamp of the EPP
folder and the train folder when the
content/artifacts change just minutes
before the release. If the folder's
timestamp changes, I believe all the
mirrors will be disabled again for a
while...
Regards,
Ed
On 16.03.2020 16:42, Markus Knauer
wrote:
Full agreement... 24h is
typically enough.
Sometimes, if it was really
urgent in the past, I
double-checked with Denis and the
webmasters in order to make them
aware that there may be a download
peak. On the other hand, the peaks
are not that high (especially for
a March release) than they used to
be.
And yes, I would definitely
vote for the RC2a version (without
aeri).
I believe 24 hours
is normally more
than enough, though
the problem in https://bugs.eclipse.org/bugs/show_bug.cgi?id=561125
is still a problem
so sooner is
probably better than
later. I feel that
it's safe to assume
that RC2a versus RC2
will be good because
the difference is
really very trivial
and I've confirmed
that the Java, JEE
and RCP packages
installed from this
basis via the
installer start up
fine...
Thanks Ed for
confirming. I will do the
downloads this evening
(Ottawa time)
Note that if you're
going to transform the
EPP repo into a simple
repository, you should
get the binary/features/plugins folders
copied up into the
2020-03 folder in
preparation as well.
I will place
all the binary/features/plugins
files in place too,
leaving just the artifacts
and content files to be
updated Wed morning.
I
will ensure that the
composites are retuning
404 in time for the
release too.
Thanks,
Jonah
Thanks for all the
heavy lifting!!
Regards,
Ed
On 16.03.2020
15:42, Jonah Graham
wrote:
Hi
folks,
When
do the files
need to be in
place for
release day? I
assume today is
better than
tomorrow.
In
that case we
need to have
RC2a vs RC2
decision ASAP.
If I don't hear
anything further
I will be making
the RC2a files
the R files.