Thanks for replies, Scott and Daniel!
Today I went the 'find references and eliminate them' way. I looked into heap
dump, found reference that could possibly screw things, and eliminated it.
After each of them I started resin, touched web.xml for a few times and
dumped heap.
I've found this OQL query to be helpful, maybe someone else will need it
someday:
select map(filter(referrers(heap.findObject("0xsome ClassLoader ref")),
"it.name != null"), "heap.objects(it)")
It lists all still-living class instances to classes loaded inside that
classloader.
More specifically, I've cleaned:
- The only ThreadLocal we've got.
- Properly closed Hibernate session - weird thing is that it did not led to
dereferencing of that LanguageType objects.
- Made two @attributes source-only - I'll have to revert that, but they were
causing to those $ProxyXX instances floating around in soft references.
- resin's SessionManager.close(): added _webApp = null; since I saw in dump
SessionManagerAdmin was referencing SessionManager that referenced Application
which was unable to garbage-collect and thus was holding classloader. Maybe
I'm wrong here, but SessionManagerAdmin was referenced by those bean
management services, and Application in question had a _sessionManager =
<null> and still was referenced over that chain.
- finally I've got rid of static ServletContext context; in one of classes.
Theoretically, i think, it should be recycled because this dependency is
circular: that class depends on ClassLoader, ClassLoader on Application,
Application on that class. But practically, as I've found, I shouldn't do
that :) After this, EnvironmentClassLoaders stopped spawning like crazy: if I
run resin and touch web.xml for 10 times, I end up with four
EnvorinmentClassLoader's for that web-app. That's still more than one, but
here I think maybe JVM is just cleaning its garbage lazily: I've observed
ClassLoader without Application in it, obviously it should be collected on
the next run.
- after that I've dropped two Application references in instance variables,
with no noticeable difference.
That list might seem lame in a sence 'he should have done all that long ago',
but a few days ago I was all like 'a classloader? what's that?' - I knew
theoretically that Classloaders exist and that garbage collector doesn't
claim referenced objects, but I didn't think much about that, I didn't know
that can cause problems.
I'll now try to carefully revert some of those changes, and in future I'll
care more about reference sanity.
P.S. to Scott:
I've looked at _scanListeners, but they're like
0 : [EMAIL PROTECTED] (64 bytes)
1 : [EMAIL PROTECTED] (113 bytes)
2 : null
so I don't think they caused that problems. I think it was just my ignorance
about static references being not necessarily good for one's health.
_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
