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 
select map(filter(referrers(heap.findObject("0xsome ClassLoader ref")), 
" != null"), "heap.objects(it)") 
It lists all still-living class instances to classes loaded inside that 
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

Reply via email to