In conversation with Gabe Montero (gmontero@redhat.com) 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:
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.
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.
In conversation with Gabe Montero (gmontero@redhat.com) doing alot of ci/cd on openshift.com he spotted we were using groovy.use.classvalue and he commented with these findings:
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.