-
Notifications
You must be signed in to change notification settings - Fork 14
consider removing -Dgroovy.use.classvalue=true #77
Description
In conversation with Gabe Montero ([email protected]) doing alot of ci/cd on openshift.com he spotted we were using groovy.use.classvalue and he commented with these findings:
Some basic internet searching took me down an interesting path:
- guidance during an old release upgrade: https://jenkins.io/doc/upgrade-guide/2.7/
- which referenced a groovy issue https://issues.apache.org/jira/browse/GROOVY-7591
- which referenced a jdk issue https://bugs.openjdk.java.net/browse/JDK-8136353
- which circled back to a groovy issue https://issues.apache.org/jira/browse/GROOVY-7683 which >presumably resolved the memory leak (v2.4.8 of groovy ...v.2.89.4 of jenkins as v2.4.11)
- and in fact the https://jenkins.io/doc/upgrade-guide/2.73/ says you no longer need this workaround
And the kicker ... this support article from cloudbees from Jan 2018 strongly advises to no longer use >this setting ... saying you could introduce a memory leak
So perhaps something to monitor, but I WILL NOT be putting this setting on by default in the openshift >jenkins image.
I'd also suggest that unless openshift.io is aware of something more recent, etc. that contradicts that >Jan 2018 article, you
should probably remove that setting as well.
The support article mentioned I assume is https://support.cloudbees.com/hc/en-us/articles/115001505172-Jenkins-hangs-due-to-Groovy-ClassInfo-deadlock which contains this msg:
"(Deprecated) Workaround
JENKINS-43197 mentions a workaround that is to add the system property -Dgroovy.use.classvalue=true on Jenkins startup to re-enable ClassValue. This is deprecated and we strongly advise to not do this. ClassValue was disabled by default to solve major memory leaks - see GROOVY-7591. Enabling ClassValue would replace a groovy memory leak by another one."
I haven't checked the impact but thought it was worth being aware of it if looking into optimizations/cleanup.