|
Given the following build flow job:
parallel(
build_list.collect { a_build_name -> return {
guard{
run_build = build(a_build_name)
} rescue {
if (run_build.result.name == "ABORTED"){
build("Job B")
}//if
}//rescue
}// return
}// collect
)//parallel
When the build flow is "aborted" or its parent is aborted,
And I view .../jenkins/monitoring url
Then I see a list of threads "cryptically-named" pool-X-thread-Y (ex. pool-16-thread-100) in a "WAITING" state. It seems the thread pool is allocated for those jobs and never gets executed or released
These threads will never get out of the "WAITING" state, except I run the following script (alternatively kill the threads individually on the threads table):
Thread.getAllStackTraces().keySet().each(){ item ->
if(item.getName().contains(thread_name_string)){
println "Interrupting thread " + item.getId() + " " + item.getName();
item.interrupt()
}
}
The above script will cause the rescue block to execute for each of the jobs in the build flow, i.e. the job queue on jenkins will show a list of "Job B" queued and their info thinks it was triggered by an already aborted job
If a user attempts the above actions multiple times without killing the threads (i.e. run jobs, and abort), the thread count will continue to increase. Eventually jenkins will be inaccessible from the web as it has exceeded the number of threads
It seems that when a build flow job is aborted, "scheduled/queued jobs" and "running" jobs are cancelled as expected, but jobs that will kick in via the rescue block seem to be orphaned, and taking up resources with regards to maximum thread count jenkins will generate
|
