2008/11/27 Gili Tzabari <[EMAIL PROTECTED]> > Looks like a definite ClassLoader problem... > > 1) I'm running under Glassfish v3 prelude 28c which I believe is the > latest version. > > 2) I verified that warp-servlet is clearing its references. > > 3) The heap dump lists the same class name multiple times. It took me a > while to figure out this occurs once for every time I redeploy the > webapp. This is even more confusing because in each ClassLoader the > object is listed with the same object id (i.e. object #1) but it isn't > the same object. So for example I see the same class name listed 5 times > but only one row displays 8 live instances, all others show 0. > > 4) Some objects show leaks. The same class shows up multiple times and > they all have non-zero instance counts. > > 5) I see Guice's Finalizer never shuts down. It keeps on creating new > instances and the old threads never shut down. > > How do I find out what is keeping the finalizer alive? If you can > point > me to the right object I will try walking the heap graph to see what is > keeping it alive. >
given that I've seen Guice unloaded from a OSGi container after using the injector then I'd really suggest you ignore the Finalizer as that's imho a red herring - it will remain around as long as the main Guice classloader is still around, but with Bob's new code it doesn't stop the classloader from being unloaded so it's not a matter of what's keeping the Finalizer alive - you need to find out what's keeping the Guice classloader alive, as this is keeping the Finalizer alive indirectly you should instead look for any references from outside of the Guice classloader, that might be keeping the classloader alive - you should also try to run finalization and GC a few times just to make sure everything has been cleared + collected have you tried creating a small testcase? (ie. Guice + small client, no use of warp) then if the leak is still there then feel free to email me that testcase + instructions Thanks, > Gili > > Stuart McCulloch wrote: > > 2008/11/27 Gili Tzabari <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> > > > > > > Stuart McCulloch wrote: > > > can you be a bit more clearer about the link from the Finalizer > > thread > > > to the Tomcat classes? are you loading Guice as a separate bundle > > > or elsewhere in the hierarchy, like inside a Tomcat classloader? > > > > Not as far as I know. I am just using Guice as a library > > inside my > > webapp. I'm not sure whether "bundle" means something different than > a > > library in this context. > > > > > > bundle is an OSGi term - since you're using GFv2 you're probably using a > > Tomcat classloader > > > > > > > here's how things worked for me - I loaded Guice in Felix as an > OSGi > > > bundle, so the Finalizer thread (which gets its own classloader) > was > > > in a classloader chained off the Guice bundle classloader > > > > What is the "Guice bundle classloader"? > > > > > > in OSGi each bundle gets its own classloader - but for you this would be > > the webapp classloader > > > > @Inject @Pitch > > with OSGi instead of having large monolithic webapps, you can break them > > into several bundles > > and then re-use bundles between applications (bundles are versioned, so > > you can have several > > versions of say Xerces safely loaded at the same time) - OSGi manages > > the wiring for you > > > > that's the idea at least - of course you may hit a few speed-bumps when > > moving legacy code to > > the OSGi model, but there are several Enterprise platforms coming out to > > help with this, like GF. > > > > here's an ongoing case study about moving to OSGi: > > > > http://raibledesigns.com/rd/entry/building_linkedin_s_next_generation > > > > > http://www.slideshare.net/linkedin/building-linkedins-next-generation-architecture-with-osgi-presentation > > http://blog.linkedin.com/?s=osgi > > > > they decided to use Spring-DM (which is Spring's OSGi support) but don't > > hold that against them ;) > > > > > the Finalizer thread hangs around until it detects that the > > classloader > > > with the reference queue (in this case the Guice bundle) is > > eligible for > > > GC, so until this happens you will see it appear as a GC root > > > > > > what might be happening in your case is that something else is > > keeping > > > the Guice classloader alive, in which case the Finalizer thread > > will stay > > > alive (but it won't cause a memory leak, because it shuts down > > when it > > > spots certain key classes being enqueued - as mentioned earlier) > > > > I suspect warp-servlet is the culprit. > > > > > > yes, I'd suggest tracing warp-servlet first to make sure the injector is > > cleared > > > > btw, the unofficial patches that I applied to Guice can be found in my > > earlier note > > ( if it's really necessary I could make the patched source available > > somewhere ) > > > > > > > once the Guice classloader is eligible for GC, the Finalizer > > thread will > > > detect it and shutdown, allowing both classloaders to be > unloaded... > > > > > > [ ps. you might also want to look at GlassFish v3 prelude ] > > > > I'm downloading it now. Is this a reasonable version? > > https://glassfish.dev.java.net/downloads/v3-prelude.html or are you > > using nightly builds from somewhere else? > > > > > > for my test I used a plain OSGi container as I wasn't using JEE - but > > the v3 prelude should be ok > > > > Gili > > > > > > -- > > Cheers, Stuart > > > > > > > > > > -- Cheers, Stuart --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
