-
Bug
-
Resolution: Fixed
-
Major
-
None
-
CentOS release 5.5 x86_64, linux-vserver, Maven 2.2+, jdk 1.6. I might affect any other linux-vserver
We ran into a problem with Hudson as detailed here, this is happening in a virtualized environment as the one described above (linux-vserver)
It's well know that vserver has some restrictions, and that it doesn't play well with the loopback interface as described here and here.
We tested hudson+vserver (this might happen in other virtualized environment as well) and found out that it's not listening in all interfaces (perhaps due to the vserver restrictions), but also, after some debugging we found out that maven-agent has a hardcoded socket connection to use only the loopback interface as it's shown here.
Shouldn't it be fixed so it add some means of fallback mechanism that makes hudson first try the loopback interface, then try with the ethernet ones?
Indeed the virtualization layer should offer a fully functional and non-restrictive environment to the upper laying processes, but unfortunately this is not the case.
Thx
UPDATE 04/18/2011
Same bug was present with maven3 under the same conditions.
[JENKINS-6795] Maven agent needs a fix for the 'hardcoded' socket connection to localhost, perhaps a fallback mechanism when it fails to connect through the loopback interface can solve this pesky issue?
Summary | Original: Maven agent needs a fix for the 'hardcoded' socket connection to localhost, perhaps a fallback mechanism when it fails to connect through the loopback interface | New: Maven agent needs a fix for the 'hardcoded' socket connection to localhost, perhaps a fallback mechanism when it fails to connect through the loopback interface can solve this pesky issue? |
Assignee | New: Olivier Lamy [ olamy ] |
Description |
Original:
We ran into a problem with Hudson as detailed [here|http://hudson.361315.n4.nabble.com/Maven-jobs-can-t-connect-java-net-ConnectException-Connection-refused-td2259346.html#a2259346], this is happening in a virtualized environment as the one described above (linux-vserver) It's well know that vserver has some restrictions, and that it doesn't play well with the loopback interface as described [here|http://linux-vserver.org/Talk:Problematic_Programs#127.0.0.1_issues] and [here|http://linux-vserver.org/Frequently_Asked_Questions_scratch#G._Problematic_Programs]. We tested hudson+vserver (this might happen in other virtualized environment as well) and found out that it's not listening in all interfaces (perhaps due to the vserver restrictions), but also, after some debugging we found out that maven-agent has a hardcoded socket connection to use only the loopback interface as it's shown [here|http://fisheye.jenkins-ci.org/browse/Hudson/tags/hudson-1_362/maven-agent/src/main/java/hudson/maven/agent/Main.java?r=31903#l119]. Shouldn't it be fixed so it add some means of fallback mechanism that makes hudson first try the loopback interface, then try with the ethernet ones? Indeed the virtualization layer *should* offer a fully functional and non-restrictive environment to the upper laying processes, but unfortunately this is not the case. Thx |
New:
We ran into a problem with Hudson as detailed [here|http://hudson.361315.n4.nabble.com/Maven-jobs-can-t-connect-java-net-ConnectException-Connection-refused-td2259346.html#a2259346], this is happening in a virtualized environment as the one described above (linux-vserver) It's well know that vserver has some restrictions, and that it doesn't play well with the loopback interface as described [here|http://linux-vserver.org/Talk:Problematic_Programs#127.0.0.1_issues] and [here|http://linux-vserver.org/Frequently_Asked_Questions_scratch#G._Problematic_Programs]. We tested hudson+vserver (this might happen in other virtualized environment as well) and found out that it's not listening in all interfaces (perhaps due to the vserver restrictions), but also, after some debugging we found out that maven-agent has a hardcoded socket connection to use only the loopback interface as it's shown [here|http://fisheye.jenkins-ci.org/browse/Hudson/tags/hudson-1_362/maven-agent/src/main/java/hudson/maven/agent/Main.java?r=31903#l119]. Shouldn't it be fixed so it add some means of fallback mechanism that makes hudson first try the loopback interface, then try with the ethernet ones? Indeed the virtualization layer *should* offer a fully functional and non-restrictive environment to the upper laying processes, but unfortunately this is not the case. Thx UPDATE 04/18/2011 Same bug was present with maven3 under the same conditions. |
Resolution | New: Fixed [ 1 ] | |
Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Code changed in jenkins
User: Mauricio Alarcon
Path:
maven-agent/src/main/java/hudson/maven/agent/Main.java
http://jenkins-ci.org/commit/maven-interceptors/78a9ccdc79afba7b9c0b3ea3d08fd333f38c2a75
Log:
FIXED
JENKINS-6795