Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads contextClassLoader being set to hudson.PluginManager$UberClassLoader.
In cases where the bug did not appear the contextClassloader was the WebAppClassLoader.
This was surprising as the code in question did not set the context classloader and was running on the Computer.threadPoolForRemoting ThreadPool.
This shows that the contextClassloader in a task submitted to this ThreadPool is not stable.
It is expected that the state of a thread run in an executor from Jenkins core is in a deterministic state.
The threadpool should be tolerant of when ad by whom Threads are created as well as ensure state is clean/stable before running tasks.
e..g - in a way similar to the Timer threads by using like the ContextResettingExecutorService
Originally reported by 
teilo, imported from: Computer.threadPoolForRemoting can be poisoned by bad code
- assignee: teilo
- status: Closed
- priority: Minor
- component(s): core
- label(s): 2.440.3-fixed
- resolution: Fixed
- resolved: 2024-03-06T14:24:59+00:00
- votes: 0
- watchers: 2
- imported: 2025-11-24
Raw content of original issue
Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads contextClassLoader being set to hudson.PluginManager$UberClassLoader.
In cases where the bug did not appear the contextClassloader was the WebAppClassLoader.
This was surprising as the code in question did not set the context classloader and was running on the Computer.threadPoolForRemoting ThreadPool.
This shows that the contextClassloader in a task submitted to this ThreadPool is not stable.
It is expected that the state of a thread run in an executor from Jenkins core is in a deterministic state.
The threadpool should be tolerant of when ad by whom Threads are created as well as ensure state is clean/stable before running tasks.
e..g - in a way similar to the Timer threads by using like the ContextResettingExecutorService
Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads contextClassLoader being set to hudson.PluginManager$UberClassLoader.
In cases where the bug did not appear the contextClassloader was the WebAppClassLoader.
This was surprising as the code in question did not set the context classloader and was running on the Computer.threadPoolForRemoting ThreadPool.
This shows that the contextClassloader in a task submitted to this ThreadPool is not stable.
It is expected that the state of a thread run in an executor from Jenkins core is in a deterministic state.
The threadpool should be tolerant of when ad by whom Threads are created as well as ensure state is clean/stable before running tasks.
e..g - in a way similar to the Timer threads by using like the ContextResettingExecutorService
Originally reported by
teilo, imported from: Computer.threadPoolForRemoting can be poisoned by bad code
Raw content of original issue