Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-11130

java.io.IOException: Unexpected termination of the channel - SEVERE: I/O error in channel Chunked connection when using jenkins-cli.jar (works on older Hudson version)

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • cli
    • None
    • * Running on SLES9 Linux server with 4 CPUs and plenty of diskspace.
      * Tomcat 7.0.14
      * JDK 1.6.0_14
      * Only ONE Master configuration - no slaves are configured
      * 3 Executors - (one less than the max number of CPUs)

      We are currently seeing the following issue using the jenkins-cli.jar
      with Jenkins 1.430. Tried going to 1.431, same issue.

      Each time we insure we have the latest matching jenkins-cli.jar using the link on the Manage Jenkins page.

      From inside a Jenkins job (I'll call it the parent) I'm trying to
      execute multiple jobs using the client jar. On the last job, I
      include the -s parameter so the parent job will not finish until the
      last job in the list is complete. The problem is that after about 15
      secs of waiting, the parent job ends (fails) with the EOF exception
      below.

      IMPORTANT INFO: When performing this exact same build using an older hudson-cli.jar with an older (pre-fork) version of Hudson v1.339, THIS WORKS. We want to move all of our builds over to the latest Jenkins version, and this is blocking us at the moment.

      We have searched all day and tried numerous things including
      reducing the number of jobs and also trying to run them sequentially.

      Stack trace seen in Console at failure:

      [workspace] $ /bin/bash -xe /opt/apache-tomcat-7.0.14_jenkins/temp/
      hudson4690948305077288103.sh
      + WAR_FOLDER=/tmp/trunk/UIToolkit1.1.2
      + rm -rf /tmp/trunk/UIToolkit1.1.2/calendar.war /tmp/trunk/
      UIToolkit1.1.2/Pay.war /tmp/trunk/UIToolkit1.1.2/OrgChart.war
      + /opt/Sun/jdk1.6.0_14/bin/java jar /opt/Sun/jdk1.6.0_14/lib/jenkins
      cli.jar s http://jenkins-host:8082/jenkins/ build XYZ_Platform
      Calendar -p SVN_PATH=trunk -p STATIC_PATH=UIToolkit1.1.2
      + /opt/Sun/jdk1.6.0_14/bin/java jar /opt/Sun/jdk1.6.0_14/lib/jenkins
      cli.jar -s http://jenkins-host:8082/jenkins/ build XYZ_Platform-Pay -p
      SVN_PATH=trunk -p STATIC_PATH=UIToolkit1.1.2
      + /opt/Sun/jdk1.6.0_14/bin/java jar /opt/Sun/jdk1.6.0_14/lib/jenkins
      cli.jar s http://jenkins-host:8082/jenkins/ build XYZ_Platform
      OrgChart -p SVN_PATH=trunk -p STATIC_PATH=UIToolkit1.1.2
      + /opt/Sun/jdk1.6.0_14/bin/java jar /opt/Sun/jdk1.6.0_14/lib/jenkins
      cli.jar s http://jenkins-host:8082/jenkins/ build XYZ_Platform
      PolicyAck -s -p SVN_PATH=trunk -p STATIC_PATH=UIToolkit1.1.2
      Sep 16, 2011 4:35:37 PM hudson.remoting.Channel$ReaderThread run
      SEVERE: I/O error in channel Chunked connection to http://jenkins-host:8082/jenkins/cli
      java.io.IOException: Unexpected termination of the channel
      at hudson.remoting.Channel$ReaderThread.run(Channel.java:1093)
      Caused by: java.io.EOFException
      at java.io.ObjectInputStream
      $BlockDataInputStream.peekByte(ObjectInputStream.java:2498)
      at
      java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1273)
      at java.io.ObjectInputStream.readObject(ObjectInputStream.java:
      348)
      at hudson.remoting.Channel$ReaderThread.run(Channel.java:1087)
      Exception in thread "main" hudson.remoting.RequestAbortedException:
      hudson.remoting.RequestAbortedException: java.io.IOException:
      Unexpected termination of the channel
      at hudson.remoting.Request.call(Request.java:149)
      at hudson.remoting.Channel.call(Channel.java:681)
      at
      hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java­:
      158)
      at $Proxy2.main(Unknown Source)
      at hudson.cli.CLI.execute(CLI.java:171)
      at hudson.cli.CLI._main(CLI.java:297)
      at hudson.cli.CLI.main(CLI.java:216)
      Caused by: hudson.remoting.RequestAbortedException:
      java.io.IOException: Unexpected termination of the channel
      at hudson.remoting.Request.abort(Request.java:273)
      at hudson.remoting.Channel.terminate(Channel.java:732)
      at hudson.remoting.Channel$ReaderThread.run(Channel.java:1117)
      Caused by: java.io.IOException: Unexpected termination of the channel
      at hudson.remoting.Channel$ReaderThread.run(Channel.java:1093)
      Caused by: java.io.EOFException
      at java.io.ObjectInputStream
      $BlockDataInputStream.peekByte(ObjectInputStream.java:2498)
      at
      java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1273)
      at java.io.ObjectInputStream.readObject(ObjectInputStream.java:
      348)
      at hudson.remoting.Channel$ReaderThread.run(Channel.java:1087)
      Build step 'Execute shell' marked build as failure
      Notifying upstream projects of job completion
      Finished: FAILURE

          [JENKINS-11130] java.io.IOException: Unexpected termination of the channel - SEVERE: I/O error in channel Chunked connection when using jenkins-cli.jar (works on older Hudson version)

          mark streit created issue -

          A few random thoughts:

          • The 15 second timeout that you mention sounds vaguely like a webserver HTTP timeout.
          • Have you tried running the same job/script outside of Jenkins? i.e. does it behave differently when run from the normal shell?
          • Is there a proxy between the build script and Jenkins? I'm guessing not because jenkins-host:8082 sounds like it will be your Tomcat instance.
          • Have you tried running with the builtin jenkins webserver instead of Tomcat? It maybe that the Tomcat HTTP layer is interacting badly with the cli library.
          • Have you captured the traffic to port 8082 with tcpdump or wireshark? Looking at the raw traffic may give some clues.
            I'm no expert on the CLI library (indeed I have never used it myself) but those are the places where I would start looking.

          Richard Mortimer added a comment - A few random thoughts: The 15 second timeout that you mention sounds vaguely like a webserver HTTP timeout. Have you tried running the same job/script outside of Jenkins? i.e. does it behave differently when run from the normal shell? Is there a proxy between the build script and Jenkins? I'm guessing not because jenkins-host:8082 sounds like it will be your Tomcat instance. Have you tried running with the builtin jenkins webserver instead of Tomcat? It maybe that the Tomcat HTTP layer is interacting badly with the cli library. Have you captured the traffic to port 8082 with tcpdump or wireshark? Looking at the raw traffic may give some clues. I'm no expert on the CLI library (indeed I have never used it myself) but those are the places where I would start looking.

          mark streit added a comment -

          Thanks so much for the comments. Here is what we know relative to your ideas:

          There are no proxies set up at all for either the Hudson instance or the Jenkins instance. 6
          Both run on 2 separate tomcat servers .... Hudson on Tomcat 6.0.18. And Jenkins on Tomcat7.0.14
          They Do run on the same physical sever.
          Each runs on diff port 8081 Hudson and 8082 Jenkins
          There is no master/slave configuration on either.
          The build process works fine using the Hudson CLI jar and older Hudson 1.339.....no issues
          The same process using the Jenkins CLI jar and Jenkins 1.431 fails....we copied over the same set of jobs
          ...cleared workspaces and attempted to run the exact same set on Jenkins and it fails with this error.
          The 15 second time seems only relevant to how many are run....we scaled back to just a few jobs and can see it blow up in 4 seconds

          Perhaps we need to drop back to Tomcat 6 and try ... I don't know.

          We have been at a loss as to why this would happen with the newer versions of everything

          Thank you again for taking time to comment

          mark streit added a comment - Thanks so much for the comments. Here is what we know relative to your ideas: There are no proxies set up at all for either the Hudson instance or the Jenkins instance. 6 Both run on 2 separate tomcat servers .... Hudson on Tomcat 6.0.18. And Jenkins on Tomcat7.0.14 They Do run on the same physical sever. Each runs on diff port 8081 Hudson and 8082 Jenkins There is no master/slave configuration on either. The build process works fine using the Hudson CLI jar and older Hudson 1.339.....no issues The same process using the Jenkins CLI jar and Jenkins 1.431 fails....we copied over the same set of jobs ...cleared workspaces and attempted to run the exact same set on Jenkins and it fails with this error. The 15 second time seems only relevant to how many are run....we scaled back to just a few jobs and can see it blow up in 4 seconds Perhaps we need to drop back to Tomcat 6 and try ... I don't know. We have been at a loss as to why this would happen with the newer versions of everything Thank you again for taking time to comment

          It would definitely be good to eliminate the difference between Tomcat 6 and 7. If it fails in one but not the other that gives a good start for analysis of the underlying cause.

          I would also try the command from the commandline (your log above gives the contents of the script so that should be easy) and again that eliminates the running from within tomcat.

          As for why things would break with newer versions it could be a simple bug; Tomcat could be being more aggressive with regards to terminating connections (to guard against denial of service attacks); or Jenkins might just be using the connections in a slightly different way.

          We need to try to eliminate causes from your environment and hopefully come up with a simple reproducible testcase that makes it easy for someone to investigate/resolve the underlying problem.

          Richard Mortimer added a comment - It would definitely be good to eliminate the difference between Tomcat 6 and 7. If it fails in one but not the other that gives a good start for analysis of the underlying cause. I would also try the command from the commandline (your log above gives the contents of the script so that should be easy) and again that eliminates the running from within tomcat. As for why things would break with newer versions it could be a simple bug; Tomcat could be being more aggressive with regards to terminating connections (to guard against denial of service attacks); or Jenkins might just be using the connections in a slightly different way. We need to try to eliminate causes from your environment and hopefully come up with a simple reproducible testcase that makes it easy for someone to investigate/resolve the underlying problem.

          mark streit added a comment -

          OK...an update. We have eliminated Tomcat 6 vs Tomcat 7 as the cause. We have tried 6.0.33, 7.0.14, 7.0.22 - same error occurs on all versions.

          Will update shortly on the results of a direct command line call outside of Jenkins using the bash shell command.

          One other item of note: Our Hudson instance (older 1.339 running on Tomcat 6 using JDK 5 only). The Jenkins instance, 1.431 (on either Tomcat 6 or Tomcat 7 is using JDK 6). Unsure if the JDK would be playing any role here.

          Thanks

          mark streit added a comment - OK...an update. We have eliminated Tomcat 6 vs Tomcat 7 as the cause. We have tried 6.0.33, 7.0.14, 7.0.22 - same error occurs on all versions. Will update shortly on the results of a direct command line call outside of Jenkins using the bash shell command. One other item of note: Our Hudson instance (older 1.339 running on Tomcat 6 using JDK 5 only). The Jenkins instance, 1.431 (on either Tomcat 6 or Tomcat 7 is using JDK 6). Unsure if the JDK would be playing any role here. Thanks

          mark streit added a comment -

          More info: We tried your suggestion of running outside from the command line rather than from within Tomcat. Still facing the same error:

          /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar -s http://XX.XX.XX.XX:8082/jenkins/ build -s Build01_Build_App_WARs -p SVN_PATH=trunk -p STATIC_PATH=Rev_1.2

          Output after about 15 secs or so:

          PID_Hudson:/opt/jenkins/scripts> /opt/jenkins/scripts/build_rev_1.2_wars.sh
          Oct 12, 2011 2:29:02 PM hudson.remoting.Channel$ReaderThread run
          SEVERE: I/O error in channel Chunked connection to http://XX.XX.XX.XX:8082/jenkins/cli
          java.io.IOException: Unexpected termination of the channel
          at hudson.remoting.Channel$ReaderThread.run(Channel.java:1093)
          Caused by: java.io.EOFException
          at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554)
          at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297)
          at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
          at hudson.remoting.Channel$ReaderThread.run(Channel.java:1087)
          Exception in thread "main" hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel

          Caused by: java.io.EOFException
          at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554)
          at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297)
          at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
          at hudson.remoting.Channel$ReaderThread.run(Channel.java:1087)
          Exception in thread "main" hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel

          mark streit added a comment - More info: We tried your suggestion of running outside from the command line rather than from within Tomcat. Still facing the same error: /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar -s http://XX.XX.XX.XX:8082/jenkins/ build -s Build01_Build_App_WARs -p SVN_PATH=trunk -p STATIC_PATH=Rev_1.2 Output after about 15 secs or so: PID_Hudson:/opt/jenkins/scripts> /opt/jenkins/scripts/build_rev_1.2_wars.sh Oct 12, 2011 2:29:02 PM hudson.remoting.Channel$ReaderThread run SEVERE: I/O error in channel Chunked connection to http://XX.XX.XX.XX:8082/jenkins/cli java.io.IOException: Unexpected termination of the channel at hudson.remoting.Channel$ReaderThread.run(Channel.java:1093) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1087) Exception in thread "main" hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1087) Exception in thread "main" hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel

          I just tried an experiment here and confirmed that things seem to work ok for me.

          • launching a single job from the cli works. I observed that a job taking 5+ minutes went ok.
            java -jar ./jenkins-cli.jar -s http://XX.XX.XX.XX:8082/ build --username XXX --password-file ./password -s XXjobnameXX
          • I created a freestyle job that executes a shell script that launches 2 other jobs via the cli. Then I launched the build from an external commandline invocation similar to the first example.
            Started by command line
            Building remotely on XXXXX
            [jenkins11130] $ /bin/sh -xe /tmp/hudson5694867157318468244.sh
            + /usr/bin/java -jar /tmp/jenkins11130/jenkins-cli.jar -s http://XX.XX.XX.XX:8082/ build --username XXXX --password-file /tmp/jenkins11130/password -s XXjob1XXX
            Completed XXjob1XXX #12 : SUCCESS
            + /usr/bin/java -jar /tmp/jenkins11130/jenkins-cli.jar -s http://XX.XX.XX.XX:8082/ build --username XXXX --password-file /tmp/jenkins11130/password -s XXjob2XXX
            Completed XXjob2XXX #1213 : SUCCESS
            Finished: SUCCESS 
            

          That was observed to work correctly.

          Notes:

          • Running jenkins 1.436 (actually Jenkins ver. 1.436-SNAPSHOT (private-10/11/2011 00:09 GMT-jenkins downloaded from ci.jenkins-ci.org earlier today)
          • Running the native winstone jenkins container.
          • Also tested against an apache reverse proxy to the same container
          • Not tested with Tomcat at all
          • Various java versions on each machine (Oracle 1.6.0_26-b03, IcedTea 6b20-1.9.9-0ubuntu1-10.04.2, IcedTea 6b22-1.10.2-0ubuntu1-11.04.1)
          • jenkins-cli.jar downloaded from
            wget http://XX.XX.XX.XX:8082/jnlpJars/jenkins-cli.jar

          Unfortunately it does not help to solve your problem but it does show that it works at some level.

          Richard Mortimer added a comment - I just tried an experiment here and confirmed that things seem to work ok for me. launching a single job from the cli works. I observed that a job taking 5+ minutes went ok. java -jar ./jenkins-cli.jar -s http://XX.XX.XX.XX:8082/ build --username XXX --password-file ./password -s XXjobnameXX I created a freestyle job that executes a shell script that launches 2 other jobs via the cli. Then I launched the build from an external commandline invocation similar to the first example. Started by command line Building remotely on XXXXX [jenkins11130] $ /bin/sh -xe /tmp/hudson5694867157318468244.sh + /usr/bin/java -jar /tmp/jenkins11130/jenkins-cli.jar -s http: //XX.XX.XX.XX:8082/ build --username XXXX --password-file /tmp/jenkins11130/password -s XXjob1XXX Completed XXjob1XXX #12 : SUCCESS + /usr/bin/java -jar /tmp/jenkins11130/jenkins-cli.jar -s http: //XX.XX.XX.XX:8082/ build --username XXXX --password-file /tmp/jenkins11130/password -s XXjob2XXX Completed XXjob2XXX #1213 : SUCCESS Finished: SUCCESS That was observed to work correctly. Notes: Running jenkins 1.436 (actually Jenkins ver. 1.436-SNAPSHOT (private-10/11/2011 00:09 GMT-jenkins downloaded from ci.jenkins-ci.org earlier today) Running the native winstone jenkins container. Also tested against an apache reverse proxy to the same container Not tested with Tomcat at all Various java versions on each machine (Oracle 1.6.0_26-b03, IcedTea 6b20-1.9.9-0ubuntu1-10.04.2, IcedTea 6b22-1.10.2-0ubuntu1-11.04.1) jenkins-cli.jar downloaded from wget http://XX.XX.XX.XX:8082/jnlpJars/jenkins-cli.jar Unfortunately it does not help to solve your problem but it does show that it works at some level.

          mark streit added a comment -

          Richard,

          Thank you very much for suggesting using Winstone as an alternative.

          • We shut down our Tomcat 7 sever (we had also tried Tomcat 6 too - same Jenkins failure)...the only thing ever running on Tomcat for us was Jenkins.
          • Started the jenkins.war using the embedded Winstone container instead. (Specified same port and number and context prefix)..so URLs would not change...
          • Making NO CHANGES to our job configurations - IT WORKED CORRECTLY this time...as it does when run from the older Hudson 1.339 on Tomcat 6.
          • We are now using Jenkins 1.434 (before trying Winstone, we tried Tomcat 7 with that version and it still fails)

          Obviously there is something wrong when trying to do this when running Jenkins on Tomcat where the jenkins-cli is being used. Used with the Winstone container, it ran flawlessly. I would have to assume something was introduced into Jenkins that is causing this. The fact that we changed NOTHING but the runtime container points to something involving running on a different container.

          Thank you again for your help...

          Mark

          mark streit added a comment - Richard, Thank you very much for suggesting using Winstone as an alternative. We shut down our Tomcat 7 sever (we had also tried Tomcat 6 too - same Jenkins failure)...the only thing ever running on Tomcat for us was Jenkins. Started the jenkins.war using the embedded Winstone container instead. (Specified same port and number and context prefix)..so URLs would not change... Making NO CHANGES to our job configurations - IT WORKED CORRECTLY this time...as it does when run from the older Hudson 1.339 on Tomcat 6. We are now using Jenkins 1.434 (before trying Winstone, we tried Tomcat 7 with that version and it still fails) Obviously there is something wrong when trying to do this when running Jenkins on Tomcat where the jenkins-cli is being used. Used with the Winstone container, it ran flawlessly. I would have to assume something was introduced into Jenkins that is causing this. The fact that we changed NOTHING but the runtime container points to something involving running on a different container. Thank you again for your help... Mark

          I was experimenting with the new Ubuntu 1110 release yesterday and gave the new Jenkins/tomcat(6) packaging a try. It installed easily and I gave the test that I tried last week another try. It worked fine both with 1.409.1 and 1.434 Jenkins. Note I used a single master setup with no slaves.

          I didn't try tomcat 7 because the Ubuntu packaging does not automatically setup Jenkins for that.

          Richard Mortimer added a comment - I was experimenting with the new Ubuntu 1110 release yesterday and gave the new Jenkins/tomcat(6) packaging a try. It installed easily and I gave the test that I tried last week another try. It worked fine both with 1.409.1 and 1.434 Jenkins. Note I used a single master setup with no slaves. I didn't try tomcat 7 because the Ubuntu packaging does not automatically setup Jenkins for that.

          mark streit added a comment -

          We have discovered something else specific to Jenkins CLI jar. Though your suggestion of running on Winstone worked well, we did discover these errors in the Console output of the build .... HOWEVER - they did NOT stop the build process from continuing:

          + /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar -s http://xx.xx.xx.xx:8082/jenkins/ build XYZ_Project-Workflow -p SVN_PATH=branches/XYZ1.4 -p STATIC_PATH=Componentv1.1.2
          Oct 19, 2011 9:01:59 AM hudson.remoting.Channel$ReaderThread run
          SEVERE: I/O error in channel Chunked connection to http://xx.xx.xx.xx:8082/jenkins/cli
          java.io.IOException: Premature EOF
          at sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:538)
          at sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:582)
          at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:669)
          at java.io.FilterInputStream.read(FilterInputStream.java:116)
          at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2504)
          at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2499)
          at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2488)
          at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2249)
          at java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2542)
          at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2552)
          at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297)
          at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
          at hudson.remoting.Channel$ReaderThread.run(Channel.java:1087)

          We CANNOT reproduce on the older Hudson 1.339 instance that uses the hudson-cli.jar. So in conclusion:

          1. Tomcat 6 or 7 WILL kill the process when we use the jenkins-cli.jar
          2. Winstone WILL NOT kill the process, but still is showing these EOF errors on every call being made, yet each job finishes and the controlling job waits properly until ALL are completed.
          3. Like you stated, we only have a single Master setup as well, w/ no slaves set up
          4. Right now, Ubuntu is not an option for us - we are using SLES9 - which will be upgraded to soon SLES11. We are constrained with this one at the moment.
          5. It seems that something in the CLI JAR between the older Hudson and newer Jenkins has changed that is causing this to occur.

          Thanks

          mark streit added a comment - We have discovered something else specific to Jenkins CLI jar. Though your suggestion of running on Winstone worked well, we did discover these errors in the Console output of the build .... HOWEVER - they did NOT stop the build process from continuing: + /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar -s http://xx.xx.xx.xx:8082/jenkins/ build XYZ_Project-Workflow -p SVN_PATH=branches/XYZ1.4 -p STATIC_PATH=Componentv1.1.2 Oct 19, 2011 9:01:59 AM hudson.remoting.Channel$ReaderThread run SEVERE: I/O error in channel Chunked connection to http://xx.xx.xx.xx:8082/jenkins/cli java.io.IOException: Premature EOF at sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:538) at sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:582) at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:669) at java.io.FilterInputStream.read(FilterInputStream.java:116) at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2504) at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2499) at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2488) at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2249) at java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2542) at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2552) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1087) We CANNOT reproduce on the older Hudson 1.339 instance that uses the hudson-cli.jar. So in conclusion: Tomcat 6 or 7 WILL kill the process when we use the jenkins-cli.jar Winstone WILL NOT kill the process, but still is showing these EOF errors on every call being made, yet each job finishes and the controlling job waits properly until ALL are completed. Like you stated, we only have a single Master setup as well, w/ no slaves set up Right now, Ubuntu is not an option for us - we are using SLES9 - which will be upgraded to soon SLES11. We are constrained with this one at the moment. It seems that something in the CLI JAR between the older Hudson and newer Jenkins has changed that is causing this to occur. Thanks

            oldelvet Richard Mortimer
            mcs13099 mark streit
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: