Community
Participate
Working Groups
I can see that some tests for Eclipse Platform fail constantly because of connection problems in our build env. Failing tests can be seen under: http://download.eclipse.org/eclipse/downloads/drops/I20120603-2100/testresults/html/org.eclipse.team.tests.cvs.core_linux.gtk.x86_6.0.html and the failure is: Could not connect to :pserver:hudsontest@hudson.eclipse.org:/cvs/org.eclipse.tests: I/O exception occurred: ProxyHTTP: java.io.IOException: proxy error: Forbidden org.eclipse.team.internal.ccvs.core.connection.CVSCommunicationException: Could not connect to :pserver:hudsontest@hudson.eclipse.org:/cvs/org.eclipse.tests: I/O exception occurred: ProxyHTTP: java.io.IOException: proxy error: Forbidden at org.eclipse.team.internal.ccvs.core.connection.Connection.open(Connection.java:134) Tests look ok on Mac and Win7 though.
Nothing has changed with the Hudson test CVS setup. But just to be sure I verified that the test repo was available from all the unix slaves: hudson-slave1:~> cvs -d :pserver:anonymous@hudson.eclipse.org:/cvs/org.eclipse.tests co testLinkFailure-1338812761336 cvs checkout: Updating testLinkFailure-1338812761336 hudson-slave2:~> cvs -d :pserver:anonymous@hudson.eclipse.org:/cvs/org.eclipse.tests co testLinkFailure-1338812761336 cvs checkout: Updating testLinkFailure-1338812761336 hudson-slave3:~> cvs -d :pserver:anonymous@hudson.eclipse.org:/cvs/org.eclipse.tests co testLinkFailure-1338812761336 cvs checkout: Updating testLinkFailure-1338812761336 hudson-slave5:~> cvs -d :pserver:anonymous@hudson.eclipse.org:/cvs/org.eclipse.tests co testLinkFailure-1338812761336 cvs checkout: Updating testLinkFailure-1338812761336 hudson-slave6:~> cvs -d :pserver:anonymous@hudson.eclipse.org:/cvs/org.eclipse.tests co testLinkFailure-1338812761336 cvs checkout: Updating testLinkFailure-1338812761336 Based on the error it looks like you aren't adding hudson.eclipse.org to the no_proxy option. -M.
> > Based on the error it looks like you aren't adding hudson.eclipse.org to the > no_proxy option. > I can confirm that ... that was "commented out" in the code I inherited. What it the "no_proxy" option. Is that something used by Hudson? Infrastructure? You mean we should set/export a variable called "no_proxy"? Right?
(In reply to comment #2) > What it the "no_proxy" option. Is that something used by Hudson? It's a shell var(Java has some similar command line flags) that is supposed to help 'direct' which hosts you need to access via a proxy and those you don't. > Infrastructure? You mean we should set/export a variable called "no_proxy"? I'm not sure how these tests are run and configured, so I can't provide any insights. But if your running these on the Hudson infra, then you need to make sure you're 'bypassing' the proxy server for requests to hudson.eclipse.org(since it's on the same network as the slaves). -M.
Ok, it seems like http://wiki.eclipse.org/Hudson#Accessing_the_Internet_using_Proxy gives a lot of good info. Still not sure why it works in some places, and not others, when we do about the same thing (e.g. on the windows machines, seems some of this should be defined by the "hudsonuser" as environment variables), but, I'll see what I can do.
(In reply to comment #4) > Ok, it seems like > http://wiki.eclipse.org/Hudson#Accessing_the_Internet_using_Proxy > gives a lot of good info. > Still not sure why it works in some places, and not others, when we do about > the same thing (e.g. on the windows machines, seems some of this should be > defined by the "hudsonuser" as environment variables), but, I'll see what I can > do. Now that I've actually read that wiki page closely, it IS saying the "no proxy" options are (should be) set correctly for each machine, part of which, that wiki page says, is you set up variables for JAVA_ARGS, ANT_ARGS, or similar that among other things specify "no proxy" for things "*.eclipse.org" which makes me realize you are saying we are somehow interfering with the default settings? I'll look into that angle ... but one additional question. The wiki mentions "http" and "ftp" a lot, but does not mention "pserver" (essentially RSH, I believe). Is that "proxied"? How could I tell if we were interfereing with that? Or if I need to set something to tell it not to use proxy for RSH requests, for linux (remember ... its working fine on the other machines).
(In reply to comment #5) > (In reply to comment #4) > > which makes me realize you are saying we are somehow interfering with the > default settings? I'll look into that angle ... Since these tests presumably 'used' to work, and as there haven't been any changes to the underlying hosts(certainly in terms of the proxy settings), it sure looks like something has changed in the tests themselves(or the underlying software). > but one additional question. The wiki mentions "http" and "ftp" a lot, but does > not mention "pserver" (essentially RSH, I believe). Is that "proxied"? How > could I tell if we were interfereing with that? Or if I need to set something > to tell it not to use proxy for RSH requests, for linux (remember ... its > working fine on the other machines). You shouldn't need to proxy CVS(at least within eclipse.org), but the fact that your getting an error in talking to the proxy, implies at least that the tests are trying to use the proxy. I'm not enough of a JAVA guru to provide advice on determining what the running processes env happens to be, or why it may be ignoring the parent process env settings. Setting 'no_proxy' at the 'shell' level should prevent things like wget from using the proxy for the given host(s). But it is(or should be) set globally. -M.
> Since these tests presumably 'used' to work, ... What gave you that impression? I'm not actually sure, but, remember, we've only been running these tests on "build.eclipse.org" for ... what 5 or 7 weeks? So, yes, they used to work on IBM hardware and setup ... but .. I do not think they have ever worked on build.eclipse.org ... though, the "test owner" would know better than I. I guess one thing I can try is to include more code to "log" current settings. That might help know what's up. FYI, so far I've not found anything specific to our Linux setup/test that would "interfere" with proxy settings. The only mention I see about RSH is a statement in a script that says # required or else RSH tries to execute in users home directory dir=${PWD} I would suspect that was required for the IBM machines? Not sure its needed here? And, ... maybe I could try commenting it out? But, seems kind of "trial and error"?
(In reply to comment #7) > > > Since these tests presumably 'used' to work, ... > > What gave you that impression? Since the CVS repo on Hudson.eclipse.org was created so Kim could test things over a year ago, I kinda figured we would have heard about it previously. > remember, we've only been running these tests on "build.eclipse.org" for ... >what 5 or 7 weeks? Fair enough. > I guess one thing I can try is to include more code to "log" current settings. > That might help know what's up. Cool. > But, seems kind of "trial and error"? At this point we need more information, which hopefully your logging and test runs will provide. Based on the proxy logs it looks like the tests were run on Slave1, and it's asking the proxy for "CONNECT hudson.eclipse.org:2401 HTTP/1.0". Do we know 'how' the request is being generated(how the port is being opened)? -M.
(In reply to comment #8) > (In reply to comment #7) > > > > > Since these tests presumably 'used' to work, ... > > > > What gave you that impression? > > Since the CVS repo on Hudson.eclipse.org was created so Kim could test things > over a year ago, I kinda figured we would have heard about it previously. > I could have easily broken something ... but, by chance I saw bug 334935 and looks like this problem has "come and gone" ... several times :) ... so, I'll have to read it closer later, but ... in the mean time ... if it reminds you of anything that might have changed on your end ... I just wanted to cross-reference it here.
*** Bug 382112 has been marked as a duplicate of this bug. ***
I think this bug has been fixed, via the discussions and changes documented in bug 372880. Such as, see bug 372880 comment 22 and subsequent. I did a "quick test" of just this cvs test and there was still two failures (down from 6 failures) and those two did not appear, on the surface, to be related to networks or proxies. (But, could still have to do with "setup", but that'd be more on our Eclipse releng side). I think those two fail on the mac too? For the "quick test" results, if you look in next few days, you'd see them at https://hudson.eclipse.org/hudson/view/Eclipse%20and%20Equinox/job/eclipse-JUnit-Linux2/158/ But, we'll count this one as fixed, for now, and confirm during a full build and test cycle. But, at least there is progress! :)
