We are heavy pipeline users and have seen some improvement in memory use since updating to this version of the plugins, however, we are now seeing 'Compressed class space' OOMs fairly frequently. (running in Java 8 + Tomcat 8) Any tips on debugging it?
-Ben On Tuesday, November 8, 2016 at 8:15:57 AM UTC-8, Karsten G. wrote: > > Hello Jesse, > > Daniel and I are Jenkins pipeline fans so we will stay tuned and report > any issues we find. Thanks again for the fast release, this saves us a lot > of time and headaches. > > Regards, > Karsten > > Am Dienstag, 8. November 2016 15:59:40 UTC+1 schrieb Jesse Glick: >> >> On Tue, Nov 8, 2016 at 3:27 AM, Daniel Weber <[email protected]> >> wrote: >> > Thanks a lot! This fixed our problem :-) >> >> Good to hear. >> >> There is test coverage demonstrating lack of leaks for basic >> scenarios, which seems to have included yours, but there can always be >> some surprises waiting in the wings. I found that when you have some >> method defined outside the build, say in a plugin: >> >> package some.permanent.pkg; >> public class SomeClass { >> @Whitelisted // go ahead, use me without worries >> public static String checkTheFrobnitz(Object whatever) {…} >> } >> >> and you call it from Pipeline script with an argument whose *runtime >> type* is defined in that script: >> >> import some.permanent.pkg.* >> stage('Checks') { >> echo "Frobnitz verified: ${SomeClass.checkTheFrobnitz(this)}" >> } >> >> then Groovy will helpfully cache the fact that >> `SomeClass.checkTheFrobnitz` on (this version of) `WorkflowScript` >> should resolve to `checkTheFrobnitz(Object)` rather than some other >> overload or weird dynamic invocation. And it will hold onto this cache >> from `SomeClass`—so a new cache entry is created on every build, whose >> “retained set” includes every class that build defined. The cache uses >> a soft reference, so the entry will *eventually* get tossed out, but >> not promptly after the end of the build (the VM argument >> `-XX:SoftRefLRUPolicyMSPerMB=1` seems to ameliorate the problem). I >> have not yet figured out a way to efficiently search for these entries >> and blow them away, so for now I just hope this case is rare in >> practice. >> >> To make things more interesting, Groovy 1.x (used in Jenkins 1.x) and >> 2.x (used in Jenkins 2.x) each have their own set of bugs in this >> area. The Java platform is not innocent either; there are poorly >> conceived caches baked into JavaBeans and Serialization which do not >> get cleared on time without some tortuous workarounds. Pipeline >> implementation code tries to clean up everything it can—enough to make >> the defined tests pass. Stay vigilant and report any reproducible >> leaks in the future: classes not unloaded, `GroovyClassLoader` >> instances never being collected. >> >> /me sighs >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8b58e763-bbfa-4d04-a0cb-1ab9cbcdf032%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
