I'm on holidays this week but I can look into it next week. In
terms of server logs, yeah, there's 22 million entries each day.
Finding patterns is a lot of work, especially when it's not clear
what I should be looking for. I remember asking what an "automatic
update" would look like and I was given a list of about 15 files.
There are probably other issues at play:
- more projects creating Maven-esque repos which cannot leverage
- new projects may not be using the mirrors
On 03/06/2015 12:51 AM, Ed Merks wrote:
I'm not sure I saw a response to Markus' question:
- is it related to bug 421779 (enable automated updates in Mars)?
Is there any pattern visible in the server logs? Some
examples I'd be interested in...
- since when does it happen, does it happen since Luna SR2?
- is it caused by some specific p2 repositories, i.e. the ones
in /releases/luna? or a project that release recently?
It would be good to know what access pattern caused several days
of the server being maxed out so we might take steps to avoid it
in the future...
On 05/03/2015 1:58 PM, Denis Roy
I agree with your assessment below. I've opened a number of
bugs against p2 over the years but there appear to be few
resources to help address the issues (this is not a complaint,
just an observation).
Indeed, p2 is very "chatty" with download.eclipse.org and I
don't think it needs to be.
On 05/03/15 02:53 AM, Ed Merks wrote:
The download server has been maxed out all week with HTTP
connections at between 9,000 to 12,000 for download1, which I
assume is the primary server for http:/download.eclipse.org:
Things like http://download.eclipse.org/releases/luna/201501121000/content.jar
were taking often more than 4 minutes to download.
Today it's finally at a more reasonable level at less than
3,000 when I used it early in the morning in Europe and I am
able to work effectively again.
Some of these problems seem to be to be fundamentally p2
problems. Eike and I looked very closely at the underlying
infrastructure as part of the Oomph work and even added
offline support for Oomph as a layer on top, but p2 itself has
a habit of downloading content and artifact files (not to
mention the artifacts themselves when not using bundle pool)
over and over again. Also p2 tries many combinations for
different potential update site configurations many of which
yield 404. In the end, it's very annoying to wait for the
same things to download again and again and when large numbers
of users are all doing that at the same time, failing, and
trying again, it becomes a serious server problem.
On 04/03/2015 4:33 PM,
LETAVERNIER Camille wrote:
We’ve received several notifications  from users who
encounter a lot of “Read time out” when they are trying
to install/update some components from the simrel
(/releases/luna) update site. It seems that it is a
general issue (not specific to Papyrus). The same thing
happens on the mars simrel update site (/releases/mars)
Are there some known
server/performances issues? Maybe related to the recent
SR2 release? Did anyone else run into these issues?