|
Sort Order:
I also seem to be encountering this issue with H1.318: Same issue here: Large maven2 project, builds fine on command line, builds fine ... Simply retrying works, eventually. Some days it's hard to get hudson to build, Oh and yes, access control is enabled and nobody pressed "abort". Code changed in hudson We've been able to reproduce this at least once, with improved debugging: ERROR: Aborted Maven execution for InterruptedIOException Hi, I have the same error with Hudson 1.339. It happens after a SVN checkout of a Maven project, when parsing the pom : At revision 6651 I get the same thing also on Hudson 1.341, again after SVN checkout: At revision 12051 After re-running the build a couple of times it works, but it means that we have to do manual builds rather than using SCM polling or scheduled builds... Question for people seeing this - what ports are you seeing this error show up with vs those times you can build successfully? The port is the numeric second-to-last argument in the Java call right before the error. The ServerSocket is getting opened on that port, and we'd be seeing a different exception, thrown before we even get to that java call, if that binding failed. So I'm wondering if there may be something blocking the master from getting to that port on the slave. There doesn't seem to be much connection between port number and the error as far as I can see. The last few builds I have done each used different port numbers but whether it failed or not tended to be associated with whether it was some time (e.g. a few hours) since hudson last did a build, as below: 1) ran build at start of week for project A: used port 4377 and aborted
Generally I find that once it has started working it will work fairly regularly but if no build happens for a few hours then the next build will abort and re-running it makes it work. By the way, I am running on a master-only configuration, no slave machines configured. Hi, in 1.327 it was already present, an Upgrade to 1.348 only added the "ERROR: Aborted Maven execution for InterruptedIOException" at the bottom of the job. The maven call I see is the following: As mbeveridge mentioned, once it startet sucessfull there are no more problems. My Ports: It happens even on big and small maven builds. I'm seeing the exact same thing. I have a really tiny Maven build; I'm just trying to get everything working correctly before I import my code, so I have a simple "Hello, world" program. This is very discouraging, to have spent a lot of time setting up Hudson only to find that half the time it can't run Maven correctly... Ricket: Are you really seeing the issue /very/ frequently? I only see it very rarely. Could you post more information about your environment (version of Hudson, Maven, Java, memory, cpu, OS, etc)? If you're really getting it more frequently than what I've seen, maybe this will help. Of course I'm just taking a stab in the dark. The issue is really just Hudson not waiting long enough before connecting, when the CPU is bogged down. I noticed my server was getting really slow so I shut down another service I was running (Artifactory) which was eating a lot of RAM and CPU, and now Hudson hasn't had a problem; the CPU and RAM have been freed so that the job is fast enough to start the Maven interceptor in time for Hudson to connect to it. By the way, I have an old slow dedicated server (AMD 1.5ghz, 256MB DDR RAM) and am running a number of things on it (Apache, MySQL, Subversion via apache, Hudson, Sonar, Artifactory not anymore). So that's why the server was too slow before. I'm just glad Hudson is pretty lightweight, at least compared to Sonar. Thanks for the response Ricket. I have been suspecting the timeout isn't set high enough; however timeout is set to 10 seconds. Surely that would be enough time? On the other hand I have no idea how much work actually takes place in that time, so 10 seconds might not be long enough. IMO there's no harm in increasing the timeout to cut down on the number of false build failures. Perhaps a 30 second timeout would do the trick? The only reason that wouldn't work is with severely overloaded machines or if there's another issue with the Maven plugin. Yes, it would be good for the timeout to be higher. Apparently 10 seconds isn't enough for a bogged-down server, and I suspect I would see this problem again if I were to try and run two builds at once. And yes, like you said, I see no reason a higher timeout would cause any problems, except it would mean waiting an extra 20 seconds if someone were trying to debug a problem with Maven or something. Probably that also explains why it tends to fail on the first build after a period of inactivity but once it gets going they seem to work ok. The first build presumably causes lots of things to be loaded and cached etc so can timeout, but once they are cached subsequent builds are ok. Is there a property that can be set to change the timeout for hudson to connect to the maven interceptor, or is that hardcoded? mbeveridge: My thoughts exactly. With only 256mb, my server was probably well out of RAM and into its 4gb page file (well, I know it to be so; I ran free and top, and even now, after stopping Artifactory, it is about 100mb into the page file with full RAM usage), and so when the Maven interceptor was started, those things were brought from the page file into RAM, and resided there long enough for the successive builds to be successful. That's my theory anyway. Hello, Didn't test it enough though for the moment. After one week of usage with 30s socket timeout), I confirm it works definitely better but it's not 100% fool proof : more or less 9 launches out of 10 are ok. From my point of view it would be great to be able to change the socket timeout from the hudson admin console. gonzalad: What system are you running Hudson on? How much RAM does it have? Is it possible that you could stop some other service and see if it works more reliably? As you probably read above, I was getting timeouts almost every time, and now after stopping the Artifactory service, I haven't tested it a whole lot but it worked every time I tested. Artifactory was using hundreds of MBs of RAM and swap space and some CPU time, but now that I cut it out, Maven is able to start fast enough to connect to Hudson. We have the same issue regarding the timeout. After that it seems the virtual machine has allocated enough memory or cpu for itself that the problem goes away. Sorry Ricket for the late answer, Code changed in hudson |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Resolved
Major
Maven build aborted before execution due to SocketTimeoutException
I am seeing this when trying to set up a new slave on 1-306. The host I had
been using to slave is still working, but when it tries to run the new slave I
get:
Started by user rsaska
since the previous
Building remotely on dev-blade-3
Updating http://s***/Connect/trunk/java-infrastructure
At revision 234
no change for http://***/Connect/trunk/java-infrastructure
build
Parsing POMs
[.] $ java
Xmx1024M -cp /home/hudson/maven-agent.jar:/usr/share/maven2.0.10/boot/classworlds-1.1.jar hudson.maven.agent.Main /usr/share/maven-2.0.10
/home/hudson/slave.jar /home/hudson/maven-interceptor.jar 56107
ERROR: Aborted
Skipping Cobertura coverage report as build was not successful...
Finished: ABORTED