While trying to diagnose a permgen leak in the JRuby support for
GlassFish, we noticed that WorkerThreads cache their most
recently-served Request object in their thread local, and don't seem to
let it go until they serve another request. For us, that means holding
on to the JRuby classloader and all 20MB of permgen that that represents
through undeploy/redeploy cycles, which we'd rather didn't happen.
Is this correct/desired behavior? If so, is there a good way to get
Grizzly to flush the caches without sending through a bunch of
lightweight requests to flush the classloaders out, preferably something
we can call from within our module on undeploy? If not, I assume I
should file a bug for it?