-
Bug
-
Resolution: Fixed
-
Minor
The Timer threads are lazily created by its executorService, so if an invocation to the Timer threads is made in a Thread context with a different contextClassloader than the default, the Timer thread will receive this contextClassloader.
Noted when fixing an analogous error in the Pipeline Timeout utility https://github.com/jenkinsci/workflow-support-plugin/pull/53 jglick – that error caused a Groovy memory leak.
- causes
-
JENKINS-60979 Installation of Plugin fails on LibertyProfile due using the wrong SocketFactory
-
- Closed
-
- links to
[JENKINS-49206] Jenkins Timer threads could get a bogus classLoader
Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
Status | Original: In Progress [ 3 ] | New: In Review [ 10005 ] |
Remote Link | New: This issue links to "PR 3272 (Web Link)" [ 19966 ] |
Labels | New: robustness |
Remote Link | New: This issue links to "Core PR #3272 (Web Link)" [ 19967 ] |
Remote Link | Original: This issue links to "Core PR #3272 (Web Link)" [ 19967 ] |
Resolution | New: Fixed [ 1 ] | |
Status | Original: In Review [ 10005 ] | New: Resolved [ 5 ] |
Code changed in jenkins
User: Sam Van Oort
Path:
core/src/main/java/hudson/util/ClassLoaderSanityThreadFactory.java
core/src/main/java/jenkins/util/Timer.java
core/src/test/java/jenkins/util/TimerTest.java
http://jenkins-ci.org/commit/jenkins/2a6fc653ee7b13adde18515b21f7e6dc1200fa8a
Log:
Fix
JENKINS-49206by ensuring Timer threads get standard classloader (#3272)JENKINS-49206by ensuring Timer threads get standard classloader