Bugzilla – Full Text Bug Listing
| Summary: | Contacting build.eclipse.org during builds seems very slow (times out?) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | Marc-André Laperle <malaperle> | ||||
| Component: | CI-Jenkins | Assignee: | Nobody - feel free to take it <nobody> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | blocker | ||||||
| Priority: | P3 | CC: | alexmonthy, cletavernier, daniel_megert, david_williams, denis.roy, jfaltermeier, jonah, mikael.barbero, mknauer, pascal, stepper, webmaster, zoltan.ujhelyi | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Marc-André Laperle
I can't reproduce the issue from the command line and your build seems to work properly now. Resolved? (In reply to Mikael Barbero from comment #1) > I can't reproduce the issue from the command line and your build seems to > work properly now. Resolved? The build always worked, the problem is that it now takes 1 hours instead of 30 mins. This is a big problem for us since our HIPP for sure can't keep up with the number of patches being pushed to Gerrit. The builds gets stuck for a very long time at [INFO] Adding repository http://build.eclipse.org/eclipse/buildtools This was not the case, a couple of days ago, this build took 32 mins: https://hudson.eclipse.org/tracecompass/view/Testing/job/tracecompass-gerrit/5097/consoleFull We can easily see that something happened when looking at the build time trend: https://hudson.eclipse.org/tracecompass/view/Testing/job/tracecompass-gerrit/buildTimeTrend It looks like something changed November 24th, around 16h (4PM). So far, I tried 1. Restart the HIPP. 2. Add build.eclipse.org in the -Dhttp.nonProxyHosts 3. Restart the HIPP. 4. Clear the job workspace I didn't help. Would you like me to provide a test pom.xml to illustrate the problem? You could run it in the shell to try to reproduce it. Created attachment 258324 [details] Build server load average today The Eclipse Build server's offers random services on a best-effort basis. Since committers are free to run anything, load fluctuates greatly as can be seen in the attached graph. In other words, relying on build.eclipse.org for downloading dependencies is unpredictable. Even accessing the URL from a browser heeds a warning you may want to pay attention to: "This software repository URL, http://build.eclipse.org/eclipse/buildtools/, is for a few utilities currently used by Eclipse production builds. It may not be long lived." I suggest you as the project to place this repo on a mission-critical server sich as download.eclipse.org or mirror this repo to a location that you have access to. (In reply to Denis Roy from comment #3) > "This software repository URL, http://build.eclipse.org/eclipse/buildtools/, > is for a few utilities currently used by Eclipse production builds. It may > not be long lived." OK, I'll ask David Williams if it can be moved (again). https://bugs.eclipse.org/bugs/show_bug.cgi?id=390821#c14 > I suggest you as the project to place this repo on a mission-critical server > sich as download.eclipse.org or mirror this repo to a location that you have > access to. OK, I'll do that if David doesn't want to move it. (In reply to Marc-Andre Laperle from comment #4) > (In reply to Denis Roy from comment #3) > > "This software repository URL, http://build.eclipse.org/eclipse/buildtools/, > > is for a few utilities currently used by Eclipse production builds. It may > > not be long lived." > > OK, I'll ask David Williams if it can be moved (again). > https://bugs.eclipse.org/bugs/show_bug.cgi?id=390821#c14 Opened bug 483198 Where was it before, and what was wrong with that location? (In reply to Denis Roy from comment #6) > Where was it before, and what was wrong with that location? It has been there since end of 2014, without problem. Before that, an older version was used from Orbit. The new version is required by eclipse.test.performance and was put on build.eclipse.org only. I think the 30-minute delay is a red herring. We did have issues with DNS and proxy this week, and all those have been resolved. Although load on build.eclipse.org fluctuates heavily, it shouldn't take 30 minutes to fetch a few files. Is there any way of getting more detailed timestamps and info as to what's going on? Right now your build is stalled at: [INFO] Resolving dependencies of MavenProject: org.eclipse.tracecompass:org.eclipse.tracecompass.analysis.os.linux.core:1.0.0-SNAPSHOT @ /jobs/genie.tracecompass/tracecompass-gerrit/workspace_3/analysis/org.eclipse.tracecompass.analysis.os.linux.core/pom.xml But it's not clear to me what it's doing. (In reply to Denis Roy from comment #8) > I think the 30-minute delay is a red herring. We did have issues with DNS > and proxy this week, and all those have been resolved. Although load on > build.eclipse.org fluctuates heavily, it shouldn't take 30 minutes to fetch > a few files. I tried to copy the update site to archive.eclipse.org so that it wouldn't contact build.eclipse.org at all, just as a test, and it went very well https://hudson.eclipse.org/tracecompass/job/tracecompass-gerrit/5137/consoleFull > Is there any way of getting more detailed timestamps and info as to what's > going on? That would be very useful, I'll see if I can add that! > Right now your build is stalled at: > [INFO] Resolving dependencies of MavenProject: > org.eclipse.tracecompass:org.eclipse.tracecompass.analysis.os.linux.core:1.0. > 0-SNAPSHOT @ > /jobs/genie.tracecompass/tracecompass-gerrit/workspace_3/analysis/org. > eclipse.tracecompass.analysis.os.linux.core/pom.xml > That steps can normally take a minute or so, maybe you caught it during that normal time. (In reply to Marc-Andre Laperle from comment #9) > I tried to copy the update site to archive.eclipse.org so that it wouldn't > contact build.eclipse.org at all, just as a test, and it went very well > https://hudson.eclipse.org/tracecompass/job/tracecompass-gerrit/5137/ > consoleFull Yup, 32 mins total time when using archive.eclipse.org instead of build.eclipse.org. I'll try to get a stack trace and time stamps from the job. BTW, should build.eclipse.org be on the non-proxy list? It could just be that the HIPP is misconfigured for non-proxies. Although I would expect it to fail completely, not take 30 mins longer. https://hudson.eclipse.org/tracecompass/view/Obsolete/job/tracecompass-temp-test/15/console 17:19:03 [INFO] Fetching p2.index from http://build.eclipse.org/eclipse/buildtools/ (0B of 128B at 0B/s) 17:19:03 [INFO] Adding repository http://build.eclipse.org/eclipse/buildtools 17:20:03 [INFO] Fetching compositeContent.jar from http://build.eclipse.org/eclipse/buildtools/ (0B of 583B at 0B/s) 17:37:04 [INFO] Fetching content.jar from http://build.eclipse.org/eclipse/buildtools/I20150811-1103/ (0B of 2.72kB at 0B/s) 17:39:05 [INFO] Fetching content.jar from http://build.eclipse.org/eclipse/buildtools/I20151104-1324/ (0B of 2.67kB at 0B/s) Without reference to build.eclipse.org, this builds takes 13s. https://hudson.eclipse.org/tracecompass/job/tracecompass-temp-test/14/console (In reply to Marc-Andre Laperle from comment #2) > > So far, I tried > > 1. Restart the HIPP. > 2. Add build.eclipse.org in the -Dhttp.nonProxyHosts > 3. Restart the HIPP. > 4. Clear the job workspace > > I didn't help. > I do not know if my information will help ... but, it might at least point you to some new tricks? To see if something is being "redirected" (such as through a proxy) I often use "wget" and for p2 repos, usually just wget the content.jar. I tried tonight, from a build.eclipse.org login shell, and the results do not look good: $ wget http://build.eclpse.org/eclipse/buildtools/derbyCore-10.11.1.1-B/content.jar --2015-11-27 21:57:35-- http://build.eclpse.org/eclipse/buildtools/derbyCore-10.11.1.1-B/content.jar Resolving build.eclpse.org... 103.224.182.246 Connecting to build.eclpse.org|103.224.182.246|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://ww38.build.eclpse.org/eclipse/buildtools/derbyCore-10.11.1.1-B/content.jar [following] --2015-11-27 21:57:35-- http://ww38.build.eclpse.org/eclipse/buildtools/derbyCore-10.11.1.1-B/content.jar Resolving ww38.build.eclpse.org... 185.53.177.30 Connecting to ww38.build.eclpse.org|185.53.177.30|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2015-11-27 21:57:36 ERROR 403: Forbidden. Note: executing wget http://build.eclpse.org/eclipse/buildtools/derbyCore-10.11.1.1-B/content.jar from a Hudson HIPP instance would probably give different results ... I'm just pointing out it does seem to be trying to go through a proxy server. (Well, I assume that's what ww38 is). = = = = = = Second, you said you added "build.eclipse.org in the -Dhttp.nonProxyHosts" but for Eclipse, p2, and Tycho (surefire, especially) it is a lot more complicated than that. A. p2 doesn't "honor" the usual "System settings" (as far as I know) and uses exclusively what is in "eclipse preferences". The "how to do" this -- for p2 director -- is documented in https://wiki.eclipse.org/Hudson#Configuring_a_proxy_for_the_p2_director That is actually the context and method that we use in our Platform tests. I know Tycho uses p2 under the covers, but not sure how to literally "set" them for Tycho? (Or if you have to). B. But, one thing I did see documented, perhaps more relevant to you? Is that Tycho's "surefire" needs some special attention when using proxies. Read about it in https://wiki.eclipse.org/Tycho/FAQ#How_to_configure_HTTP_proxy_settings_during_test_execution.3F I have no first-hand knowledge or experience with it ... just saw it during a google search look for the "p2 director" reference. = = = = = = = = [Dennis, in case you are curious, the reason I do not just "plop this up on downloads" somewhere is that this is a "test-time only" dependency, not something we distribute and has not been through the "distribute CQ" process. Last I heard, putting something on "downloads" is the same as "distributing" is, and must go through full IP process. We might do that someday -- with Marc-Andre's help :) -- but unless you say otherwise, I think we need to wait for the process, before putting on 'downloads'. Just thought you might want to know.] David, you misspelled eclipse in the host name. (In reply to Denis Roy from comment #13) > David, you misspelled eclipse in the host name. Oh, yes, I meant to do that, just for illustration. [I wish.] :) Corrected spelling looks much better. Hope the "tip" is still helpful in general. I know wget DOES respect the "system settings" for proxies but also see in man pages it has a "--no-proxies" options to ignore those, and not use proxies. I'm sure this command, and its options, would not catch ALL network problems, but I've found it useful. = = = = = = = = = $ wget http://build.eclipse.org/eclipse/buildtools/derbyCore-10.11.1.1-B/content.jar --2015-11-28 01:04:40-- http://build.eclipse.org/eclipse/buildtools/derbyCore-10.11.1.1-B/content.jar Resolving build.eclipse.org... 172.25.25.57 Connecting to build.eclipse.org|172.25.25.57|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 10940 (11K) [application/x-jar] Saving to: `content.jar' 100%[==========================================================================================>] 10,940 --.-K/s in 0s 2015-11-28 01:04:40 (642 MB/s) - `content.jar' saved [10940/10940] (In reply to David Williams from comment #14) > (In reply to Denis Roy from comment #13) > ... but I've found it useful. So useful in fact, I tried running that 'wget' command on our Platform performance machine, and it does go through a proxy: --2015-11-28 04:41:26-- http://build.eclipse.org/eclipse/buildtools/derbyCore-10.11.1.1-B/content.jar Resolving proxy.eclipse.org... 172.30.206.220 Connecting to proxy.eclipse.org|172.30.206.220|:9898... connected. Proxy request sent, awaiting response... 200 OK Fine, as long as your application recognizes the proxy settings .... but, p2 does not -- without "intervention". AND, I do not think the IP address of "build.eclpse.org" "matches" the pattern that is given in https://wiki.eclipse.org/Hudson#Configuring_a_proxy_for_the_p2_director That is the "nonproxiedhosts" pattern of nonProxiedHosts=172.30.206.* (It does not match if I login to 'shell' and ping myself). I've noticed the "system settings" set it to a value that requires a DNS: nonProxiedHosts=*.eclipse.org. Maybe that's been true for a long time? But, does not match the documentation at https://wiki.eclipse.org/Hudson#Configuring_a_proxy_for_the_p2_director I have been looking at this until 5 AM, because our performance tests started failing for the same reason as this bug, beginning on the 25th. And, they still are. I will admit, I may not be setting Eclipse "preferences" early enough for when we fetch/install derby ... I've more work to do investigating that -- But clearly something has changed. And, in our case, at least, "going to the downloads server instead" is not a good option. We get several things from "build.eclipse.org" and, as another case, we run a little database on build.eclipse.org. That might still work since it does not use port 80. I don't know. I'm just saying ... oh, you know what I'm saying ... I'm saying it's late or early, depending on your timezone. :) (In reply to David Williams from comment #15) > I have been looking at this until 5 AM, because our performance tests > started failing for the same reason as this bug, beginning on the 25th. I tried every combination of proxy/non-proxy settings from our performance test machine and could not get it to work. Where "it" means getting p2 to "find" something from "build.eclipse.org" and install it. (We have a 15 minute timeout on that task, so not sure if it would have eventually worked, but .. 15 minutes is about 10 times what is normally needed, so I don't think it reasonable to just increase that). I was able to work around the problem by using, with p2, a URL of file:///shared/eclipse/buildtools/ instead of http://build.eclpse.org/eclipse/buildtools/ That's not too bad, given we define this as a "non-distributed test-time dependency", but is less than ideal for "general purpose builds". But it is unclear to me if "build.eclipse.org" is *supposed to be* proxied from Hudson servers? Or not? Once I know the answer to that, we can discuss what the proper values of "nonproxiedhosts" is supposed to be. For example, seems it should not be "*.eclipse.org" if build.eclipse.org is supposed to be proxied. > But it is unclear to me if "build.eclipse.org" is *supposed to be* proxied
> from Hudson servers? Or not?
Our default exclude list is "*.eclipse.org" in the shell environment, in the Hudson environment and in the Maven environment, so it definitely should not be proxied.
But Java's handling of Proxies (and most every Java-based app) is shoddy at best.
(In reply to Denis Roy from comment #17) > > But it is unclear to me if "build.eclipse.org" is *supposed to be* proxied > > from Hudson servers? Or not? > > Our default exclude list is "*.eclipse.org" in the shell environment, in the > Hudson environment and in the Maven environment, so it definitely should not > be proxied. > > But Java's handling of Proxies (and most every Java-based app) is shoddy at > best. Ok, so comment 15, where I used wget from the performance machine's Hudson instance, implies somethings wrong with "settings"? Or, that something's wrong with "Hudson" (since it is after all, running under Java? --2015-11-28 04:41:26-- http://build.eclipse.org/eclipse/buildtools/derbyCore-10.11.1.1-B/content.jar Resolving proxy.eclipse.org... 172.30.206.220 Connecting to proxy.eclipse.org|172.30.206.220|:9898... connected. Proxy request sent, awaiting response... 200 OK Thank you, The performance instance is one of those pre-HIPP instances that should follow in the footsteps of the shared instance, and be HIPP-ified so it can inherit the common settings. *.eclipse.org was not defined in the no_proxy list and wget failed, so I've added it. wget now succeeds, and I've restarted the perf Hudson instance. (In reply to Denis Roy from comment #19) > The performance instance is one of those pre-HIPP instances that should > follow in the footsteps of the shared instance, and be HIPP-ified so it can > inherit the common settings. > > *.eclipse.org was not defined in the no_proxy list and wget failed, so I've > added it. wget now succeeds, and I've restarted the perf Hudson instance. Thank you. And, am I correct in assuming that the instructions at https://wiki.eclipse.org/Hudson#Configuring_a_proxy_for_the_p2_director should be changed to 'match'? That is nonProxiedHosts=172.30.206.* be changed to nonProxiedHosts=*.eclipse.org? (Or, is it the same thing?) Also, this may be minor, but notice how, in that example, we set systemProxiesEnabled=true For Windows, that's some "registry settings", for Linux, that's some "GConf" settings. Less sure about the Mac but assuming something similar? Having *those* system settings can help some parts of modern Java get the right proxies -- I have heard, via the Ant Manual: https://ant.apache.org/manual/proxy.html Do you all 'set' those for the Windows machine or any of the Linux installs? Mostly curious, not sure we need it. One more question -- for now :) Do I recall you saying somewhere that we (i.e. Eclipse.org) use "socks proxies" under the covers? I ask since I *think* those can be set too, in Eclipse preferences, but not positive. And not to be nit-picky, but I've looked at "configuration" of the Shared Instance of Hudson, and it seems http.nonProxyHosts is configured inconsistently. Early in the config, it has -Dhttp.nonProxyHosts="172.30.206.*" For things like "MAVEN_OPTS" and ANT_OPTS. Then later, under "Global Maven Options" it has -Dhttp.nonProxyHosts=hudson.eclipse.org|172.30.206.*|download.eclipse.org I even see one "environment variable" defined (outside of Hudson, I believe) as no_proxy=localhost,172.30.206.*,172.30.206.0,172.25.25.*,172.25.25.0,hudson.eclipse.org,127.0.0.1,download.eclipse.org I do not know if this causes any problems, but is confusing. I'm mostly pointing this out trying to figure out what values should be in https://wiki.eclipse.org/Hudson#Configuring_a_proxy_for_the_p2_director (And, what values *we* should use when configuring Eclipse according to those directions at the wiki page). Mikael, could a step have been missed with reverting the Hudson install to 3.2.2? Or have they always been inconsistent? What I find odd is that if it was just a proxy issue, wouldn't it completely fail? In Trace Compass build, it still ends up downloading the required jar and it succeeds. (In reply to David Williams from comment #21) > Mikael, could a step have been missed with reverting the Hudson install to > 3.2.2? Or have they always been inconsistent? It has always been like this. These values come from the old shared instance and I did not touch them. We can try to homogenize all of this if you want. (In reply to Mikael Barbero from comment #23) > (In reply to David Williams from comment #21) > > Mikael, could a step have been missed with reverting the Hudson install to > > 3.2.2? Or have they always been inconsistent? > > It has always been like this. These values come from the old shared instance > and I did not touch them. We can try to homogenize all of this if you want. I don't really care about homogenizing them. What I want to know is what we in Eclipse have to specify in "preferences" to get p2 to work. And, "speak of the devil". I changed our "test preferences" to use "*.eclpse.org" because I thought that's what Dennis said it should be. But in our tests today, saw the "connection timeout" failure below. And notice a few lines above it was an "informative message" about what the value of "http.nonProxyHosts" was before my preferences overrode it. That is a lot different than the "*.eclipse.org" that I am specifying. I am fine changing to 127.0.0.1|localhost|*.localhost|local|*.local|169.254/16|*.169.254/16|hudson.eclipse.org|*.hudson.eclipse.org|download.eclipse.org|*.download.eclipse.org if that is the recommended value. !ENTRY org.eclipse.core.net 1 0 2015-12-01 14:38:55.561 !MESSAGE System property http.nonProxyHosts has been set to 127.0.0.1|localhost|*.localhost|local|*.local|169.254/16|*.169.254/16|hudson.eclipse.org|*.hudson.eclipse.org|download.eclipse.org|*.download.eclipse.org by an external source. This value will be overwritten using the values from the preferences !ENTRY org.eclipse.core.net 1 0 2015-12-01 14:38:55.563 !MESSAGE System property https.proxyHost has been set to proxy.eclipse.org by an external source. This value will be overwritten using the values from the preferences !ENTRY org.eclipse.core.net 1 0 2015-12-01 14:38:55.564 !MESSAGE System property https.proxyPort has been set to 9898 by an external source. This value will be overwritten using the values from the preferences !ENTRY org.eclipse.equinox.p2.transport.ecf 2 0 2015-12-01 14:40:10.746 !MESSAGE Connection to http://download.eclipse.org/eclipse/updates/4.6-I-builds/I20151201-1100/p2.index failed on Operation timed out. Retry attempt 0 started !STACK 0 java.net.ConnectException: Operation timed out at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.eclipse.ecf.internal.provider.filetransfer.httpclient4.ECFHttpClientProtocolSocketFactory.connectSocket(ECFHttpClientProtocolSocketFactory.java:86) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177) at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144) at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:131) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.performConnect(HttpClientRetrieveFileTransfer.java:1077) at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.access$0(HttpClientRetrieveFileTransfer.java:1068) at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer$1.performFileTransfer(HttpClientRetrieveFileTransfer.java:1064) at org.eclipse.ecf.filetransfer.FileTransferJob.run(FileTransferJob.java:73) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) *** Bug 483381 has been marked as a duplicate of this bug. *** *** Bug 483412 has been marked as a duplicate of this bug. *** Denis, Matt, it seems that there really is something wonky with the proxy resolution. I've created a sample job on CBI's HIPP that wget some random stuff at eclipse: wget http://download.eclipse.org/eclipse/updates/4.6-I-builds/I20151201-1100/p2.index wget http://download.eclipse.org/modeling/emf/emf/updates/2.11.x/core/S201508060404/plugins/org.eclipse.emf.ecore.edit_2.9.0.v20150806-0404.jar.pack.gz wget http://download.eclipse.org/tools/orbit/downloads/drops/S20151016170251/repository/plugins/org.apache.felix.gogo.shell_0.10.0.v201212101605.jar.pack.gz and it really takes a long time to fetch, e.g. the last one on run #2 (https://hudson.eclipse.org/cbi/job/test-build.eclipse.org/2/console) first timed out (3 mins) and on the next retry it is fetched properly in less than 1 sec. (In reply to Mikael Barbero from comment #27) > Denis, Matt, it seems that there really is something wonky Not sure whether related, but also accessing downloads is very slow, e.g. http://download.eclipse.org/eclipse/downloads/ is unusable slow. > Denis, Matt, it seems that there really is something wonky with the proxy > resolution. Agreed. Matt, please test & fix this. > Not sure whether related, but also accessing downloads is very slow, e.g. > http://download.eclipse.org/eclipse/downloads/ > is unusable slow. I highly doubt it is. We're having issues throwing bits to the outside world, and I'm convinced it's not on our end. But we are looking into it. I built a test job here: https://hudson.eclipse.org/dash/job/test and after poking at things it looks like one of the slave DNS servers was resolving requests using the wrong zone. I think I've got that nailed down, but would appreciate some confirmation that has resolved the issues people are seeing. If it hasn't I may need some help to tweak the test job to better replicate what builds are doing. -M. I got several builds through without problems now. Thanks! Contacting build.eclipse.org is still slow, I think this is separate from the other bugs that were opened (download.eclipse.org, repo.eclipse.org). Contacting download.eclipse.org was working normally for us, at least at the time of this bug creation. ... 12:46:22 [INFO] Fetching p2.index from http://build.eclipse.org/eclipse/buildtools/ (0B of 128B at 0B/s) 12:46:22 [INFO] Adding repository http://build.eclipse.org/eclipse/buildtools 13:00:23 [INFO] Fetching p2.index from http://download.eclipse.org/cbi/updates/license/ (0B of 128B at 0B/s) 13:00:23 [INFO] Adding repository http://download.eclipse.org/cbi/updates/license ... https://hudson.eclipse.org/tracecompass/job/tracecompass-master-sonar/251/console I'm not able to replicate these timeouts with my test job and tracing the tracecompass calls trough the logs doesn't seem to be showing any HTTP errors. @Marc: How hard would it be for you to add the failing part of your build to my test job? -M. (In reply to Eclipse Webmaster from comment #33) > I'm not able to replicate these timeouts with my test job and tracing the > tracecompass calls trough the logs doesn't seem to be showing any HTTP > errors. > > @Marc: > > How hard would it be for you to add the failing part of your build to my > test job? > > -M. Thanks for trying! I would not be very hard. I made a small example project here: https://github.com/MarkZ3/testNullAnnotations.git We would just need to set the job to clone this an call maven. I have such a job here https://hudson.eclipse.org/tracecompass/view/Obsolete/job/tracecompass-temp-test/24/console I've copied Marcs test job via c&p, and while the first run took 44s(https://hudson.eclipse.org/dash/job/test/32) the rest seem to be in the 10s range. I'll give it a while and run them again. -M. I can report Orbit and "build machine" are building fine. The shared instance Hudson is "testing" fine. Only problem that remains is with performance test machine. There, the call to p2 director to install a feature from "build.eclipse.org" times out after 15 minutes. Still. On this machine, the proxy setting appears set to the following (in ANT_OPTS, and similar). -Dhttp.nonProxyHosts="*.eclipse.org" Was it ever decided what the proxy setting should be? I see on shared instance, it appears set to -Dhttp.nonProxyHosts="download.eclipse.org|172.30.206.*" (In reply to David Williams from comment #36) > I can report Orbit and "build machine" are building fine. > > The shared instance Hudson is "testing" fine. > > Only problem that remains is with performance test machine. There, the call > to p2 director to install a feature from "build.eclipse.org" times out after > 15 minutes. Still. On this machine, the proxy setting appears set to the > following (in ANT_OPTS, and similar). > > -Dhttp.nonProxyHosts="*.eclipse.org" > > Was it ever decided what the proxy setting should be? > > I see on shared instance, it appears set to > > -Dhttp.nonProxyHosts="download.eclipse.org|172.30.206.*" And, meant to say, the speed "outside" Eclipse is the snappiest I have ever seen! :) Thanks! (In reply to Eclipse Webmaster from comment #35) > I've copied Marcs test job via c&p, and while the first run took > 44s(https://hudson.eclipse.org/dash/job/test/32) the rest seem to be in the > 10s range. I'll give it a while and run them again. > > -M. My test job runs fast now too. I don't know what's changed. It could be that the server was under load, but it's quite odd that it would take up to 20-25 mins minutes instead of a few seconds. (In reply to David Williams from comment #36) > ... > > Only problem that remains is with performance test machine. Nevermind. Performance machine to 'build.eclipse.org' is fine. I introduced a typo when trying to find a fix from "things going bad". > On this machine, the proxy setting appears set to the > following (in ANT_OPTS, and similar). > > -Dhttp.nonProxyHosts="*.eclipse.org" > > Was it ever decided what the proxy setting should be? > > I see on shared instance, it appears set to > > -Dhttp.nonProxyHosts="download.eclipse.org|172.30.206.*" I would appreciate a concrete answer to this question, and an update to https://wiki.eclipse.org/Hudson#Configuring_a_proxy_for_the_p2_director = = = = = = = = = = = P.S. I uncovered my typo after creating a "test job" and finding that things worked fine there. That test job is https://hudson.eclipse.org/perftests/job/aTestOfDownloadsAndBuildTools/ You are welcome to it if you want to build up your arsenal of sanity checks. It currently runs on Linux only, but easy to extend to Mac and Windows. = = = = = = = = = = = Thank you for everyone's work on these multiple issues. Here is another "confession". I even added an "external site" to get a p2 update from -- to really test the proxies -- and, somehow, my test program works, even if I do NOT specify the 'hard-to-do' "preferences" file, as documented in https://wiki.eclipse.org/Hudson#Configuring_a_proxy_for_the_p2_director And that is both on the performance machine, referenced earlier, and I also tried "slave 2" on the shared instance. https://hudson.eclipse.org/shared/view/Eclipse%20and%20Equinox/job/aTestOfDownloadsAndBuildTools/ So, not sure if that is a temporary glitch :) Or, if something has changed in Java, or p2 ... or an aspect of the "type" of proxy you are using? Just thought I'd let you know. One of these days when I get bored, maybe I'll try the Windows slave and the Mac slave too. Thanks again, Ok, sounds like this is 'fixed'. Please re-open if I'm wrong. -M. |