hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset

Jenkins JIRA | trejkaz | 8 years ago
  1. 0

    Occasionally something happens (network failure, someone shuts down the machine, etc.) which makes a slave build fail. In this situation, currently Hudson gives an exception like this: hudson.util.IOException2: Failed to join the process at hudson.Proc$RemoteProc.join(Proc.java:231) at hudson.tasks.Ant.perform(Ant.java:180) at hudson.model.Build$RunnerImpl.build(Build.java:138) at hudson.model.Build$RunnerImpl.doRun(Build.java:113) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:244) at hudson.model.Run.run(Run.java:842) at hudson.model.Build.run(Build.java:88) at hudson.model.ResourceController.execute(ResourceController.java:70) at hudson.model.Executor.run(Executor.java:90) Caused by: java.util.concurrent.ExecutionException: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset at hudson.remoting.Request$1.get(Request.java:165) at hudson.remoting.Request$1.get(Request.java:134) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:32) at hudson.Proc$RemoteProc.join(Proc.java:223) ... 8 more This in itself is fine, but it then in turn marks the build as failed. This results in Hudson thinking the changes which occurred for this build were the cause for the build. This causes two problems: 1. When the build is re-run and then works, Hudson won't list the changes which occurred before the broken build as being changes which belong to the new build. 2. If you are running the CI Game plugin, the unlucky soul who committed the changes immediately before Hudson broke gets -10.0 points. IMO in this situation the points should be docked against Hudson itself, or some other equivalent placeholder player... On a larger scale, *any* build which fails due to Hudson itself should not be marked as failed for the same reason; this just happens to be the most common situation which we encounter in practice.

    Jenkins JIRA | 8 years ago | trejkaz
    hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset
  2. 0

    Occasionally something happens (network failure, someone shuts down the machine, etc.) which makes a slave build fail. In this situation, currently Hudson gives an exception like this: hudson.util.IOException2: Failed to join the process at hudson.Proc$RemoteProc.join(Proc.java:231) at hudson.tasks.Ant.perform(Ant.java:180) at hudson.model.Build$RunnerImpl.build(Build.java:138) at hudson.model.Build$RunnerImpl.doRun(Build.java:113) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:244) at hudson.model.Run.run(Run.java:842) at hudson.model.Build.run(Build.java:88) at hudson.model.ResourceController.execute(ResourceController.java:70) at hudson.model.Executor.run(Executor.java:90) Caused by: java.util.concurrent.ExecutionException: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset at hudson.remoting.Request$1.get(Request.java:165) at hudson.remoting.Request$1.get(Request.java:134) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:32) at hudson.Proc$RemoteProc.join(Proc.java:223) ... 8 more This in itself is fine, but it then in turn marks the build as failed. This results in Hudson thinking the changes which occurred for this build were the cause for the build. This causes two problems: 1. When the build is re-run and then works, Hudson won't list the changes which occurred before the broken build as being changes which belong to the new build. 2. If you are running the CI Game plugin, the unlucky soul who committed the changes immediately before Hudson broke gets -10.0 points. IMO in this situation the points should be docked against Hudson itself, or some other equivalent placeholder player... On a larger scale, *any* build which fails due to Hudson itself should not be marked as failed for the same reason; this just happens to be the most common situation which we encounter in practice.

    Jenkins JIRA | 8 years ago | trejkaz
    hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset
  3. 0

    Unexpected termination of the channel

    Google Groups | 6 years ago | Lynn Lin
    hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    General Debug Questions?

    Google Groups | 6 years ago | David Beck
    hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel
  6. 0

    Jenkins users - Unexpected termination of the channel

    nabble.com | 4 months ago
    hudson.remoting.RequestAbortedException: java.io.IOException: > Unexpected termination of the channel

    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. hudson.remoting.RequestAbortedException

      java.net.SocketException: Connection reset

      at hudson.remoting.Request$1.get()
    2. Hudson :: Remoting Layer
      FutureAdapter.get
      1. hudson.remoting.Request$1.get(Request.java:165)
      2. hudson.remoting.Request$1.get(Request.java:134)
      3. hudson.remoting.FutureAdapter.get(FutureAdapter.java:32)
      3 frames
    3. Hudson
      Proc$RemoteProc.join
      1. hudson.Proc$RemoteProc.join(Proc.java:223)
      1 frame