Skip to main content
Jump to: navigation, search

Difference between revisions of "I'm aborting a build but it's not happening. What's going on?"

Line 7: Line 7:
 
At this point, your browser is back, but the actual abort process happens from here asynchronously.  
 
At this point, your browser is back, but the actual abort process happens from here asynchronously.  
  
#The thread gets the interrupt signal. How quickly this happens depends on what the executor is doing at the time of the interruption. Specifically, an executor thread can only be interrupted in "interruption points" due to the Java design.<br>
+
# The thread gets the interrupt signal. How quickly this happens depends on what the executor is doing at the time of the interruption. Specifically, an executor thread can only be interrupted in "interruption points" due to the Java design.
*Waiting for a completion of a child process (for example, maybe the build is running Ant) is an interruption point. That means if the executor was doing that, it gets interrupted instantaneously.
+
#* Waiting for a completion of a child process (for example, maybe the build is running Ant) is an interruption point. That means if the executor was doing that, it gets interrupted instantaneously.
*Waiting for a computation on a slave is an interruption point.
+
#* Waiting for a computation on a slave is an interruption point.
*Waiting for file or network I/O is not an interruption point. This often causes the problem where a build appears to be un-abortable. For example, checking out a Subversion repository falls in this category.
+
#* Waiting for file or network I/O is not an interruption point. This often causes the problem where a build appears to be un-abortable. For example, checking out a Subversion repository falls in this category.
*Normal computation is also not an interruption point.
+
#* Normal computation is also not an interruption point.
#The executor performs a clean up operation. This depends on what it was doing by the time it noticed the interruption.
+
# The executor performs a clean up operation. This depends on what it was doing by the time it noticed the interruption.
#Executor starts unwinding the stack, and eventually it finishes the unwinding. At this point, the build is marked as aborted and executor gets back to the idle status.
+
#* If it was waiting for a completion of a child process, Hudson will search for all the descendant processes and kill them all. On Unix, this is done through {{java.lang.UnixProcess.destroyProcess}}, which sends [SIGTERM|http://en.wikipedia.org/wiki/SIGTERM] on Sun's JREs. On Windows, this is done through [TerminateProcess|http://msdn.microsoft.com/en-us/library/ms686714(VS.85).aspx] API.
 +
#* If it was waiting for a completion of some computation in a slave, the thread that's performing the remote computation is interrupted asynchronously. How quickly that threads gets interrupted depends on what that thread is doing. See above.
 +
# Executor starts unwinding the stack, and eventually it finishes the unwinding. At this point, the build is marked as aborted and executor gets back to the idle status.
 +
 
 +
 
  
 
== If your build isn't aborting  ==
 
== If your build isn't aborting  ==
  
 
Check the thread dump <code>http://yourserver/hudson/threadDump</code> and look for the executor thread in question — they are named after the slave and executor number. That'll normally tell you where the thread is, and often reveals why it's not responding to an interruption.
 
Check the thread dump <code>http://yourserver/hudson/threadDump</code> and look for the executor thread in question — they are named after the slave and executor number. That'll normally tell you where the thread is, and often reveals why it's not responding to an interruption.

Revision as of 20:38, 14 December 2012

When you click that [x] icon from the UI, the following things happen:

  1. Browser sends a request to the server.
  2. The server interrupts (via Thread.interrupt()) the thread (AKA executor thread) that is responsible for carrying out a build.
  3. The server returns

At this point, your browser is back, but the actual abort process happens from here asynchronously.

  1. The thread gets the interrupt signal. How quickly this happens depends on what the executor is doing at the time of the interruption. Specifically, an executor thread can only be interrupted in "interruption points" due to the Java design.
    • Waiting for a completion of a child process (for example, maybe the build is running Ant) is an interruption point. That means if the executor was doing that, it gets interrupted instantaneously.
    • Waiting for a computation on a slave is an interruption point.
    • Waiting for file or network I/O is not an interruption point. This often causes the problem where a build appears to be un-abortable. For example, checking out a Subversion repository falls in this category.
    • Normal computation is also not an interruption point.
  2. The executor performs a clean up operation. This depends on what it was doing by the time it noticed the interruption.
  3. Executor starts unwinding the stack, and eventually it finishes the unwinding. At this point, the build is marked as aborted and executor gets back to the idle status.


If your build isn't aborting

Check the thread dump http://yourserver/hudson/threadDump and look for the executor thread in question — they are named after the slave and executor number. That'll normally tell you where the thread is, and often reveals why it's not responding to an interruption.

Back to the top