2008/11/27 Gili <[EMAIL PROTECTED]> > > Stuart, > > I just tried your build against Glassfish v2ur2 and I am seeing the > following memory leak: > > com.google.inject.internal.base.internal.Finalizer (thread) -> classes > (Tomcat) -> elementData[149] -> rootInjector (warp-servlet) -> value - > > jitBindings (Guice) -> table[33] -> next -> value -> internalFactory > (Guice) -> initializable (Guice) -> val$instance (Guice) -> instance > (Guice) -> GuiceServlet (Jersey). > > Please let me know whether you understand this leak or whether you > need me to debug this further (I am more than willing). >
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? 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 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) so I'd ignore the Finalizer chain for now, and see if something else is keeping that classloader alive - FWIW, I also used System.gc() and System.runFinalization() a few times to eagerly unload the classes. 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 ] Gili > > On Nov 26, 12:17 pm, "Stuart McCulloch" <[EMAIL PROTECTED]> wrote: > > 2008/11/26 o_swas <[EMAIL PROTECTED]> > > > > > > > > > OK, thank you for all the replies! So it sounds like Spring isn't > > > necessarily the problem with releasing memory upon web app deploy > > > Guice might have the same problems, too. > > > > FYI, I just tested a locally patched version of Guice that has Bob's new > > implementation of FinalizerReferenceQueue from Google-Collections: > > > > http://code.google.com/p/google-collections/issues/detail?id=92 > > http://code.google.com/p/google-guice/issues/detail?id=227 > > > > and I'm happy to say that I can now load Guice into an OSGi container, > > use it with various client bundles, and then completely unload both the > > client and Guice bundles - no leak, all without restarting the container! > > > > this is amazing, and the FinalizerReferenceQueue solution is really cool > > > > in case anyone wants to try it out, you can grab the patched binary from: > > > > http://peaberry.googlecode.com/svn/branches/spike/lib/build/google-gu... > > > > and the various patches I applied (sans binary jars) can be found here: > > > > http://peaberry.googlecode.com/svn/branches/spike/lib/build/google-gu... > > > > http://peaberry.googlecode.com/svn/branches/spike/lib/build/google-gu... > > > > http://peaberry.googlecode.com/svn/branches/spike/lib/build/google-gu... > > > > note that this is an unofficial, unsupported patch of Guice, and there's > > no guarantee at all that these patches will get into the official > release! > > (especially the use of proguard to trim down the binary - which is just > > my own personal workaround until the Guice team fixes issue 264) > > > > but as a proof-of-concept, it is possible to completely unload Guice :) > > > > Can anybody comment on runtime performance of Spring vs. Guice? Will > > > > > > > > > Guice scale any better (or worse) than Spring? How does startup speed > > > compare? Anything else I should know? > > > > > Thanks to all!! > > > > > -Ryan > > > > > On Nov 25, 10:56 pm, "Stuart McCulloch" <[EMAIL PROTECTED]> wrote: > > > > 2008/11/26 Dhanji R. Prasanna <[EMAIL PROTECTED]> > > > > > > > On Tue, Nov 25, 2008 at 11:22 AM, jordi <[EMAIL PROTECTED]> wrote: > > > > > ... > > > > > > > > Looking at the console log i see this message when redeploying: > > > > > > > > A C3P0Registry mbean is already registered. This probably means > that > > > an > > > > > > application using c3p0 was undeployed, but not all > PooledDataSources > > > were > > > > > > closed prior to undeployment. This may lead to resource leaks > over > > > time. > > > > > > Please take care to close all PooledDataSources. > > > > > > > > I guess i'll have to clean up some resources before reloading > > > context.. > > > > > > > Are you calling close() on the Hibernate SessionFactory? This is > very > > > > > important. > > > > > > +1, or to paraphrase a popular saying: "close early close often" ;) > > > > > > > Also I recommend just bringing down the appserver every time. This > > > > > idea that webapps can be redeployed while the server remains up is > a > > > > > bit silly to me. > > > > > > you might want to look at GlassFish or the new SpringSource > Application > > > > Platform > > > > (or indeed any of the upcoming OSGi based web servers) - there are > many > > > > demos > > > > and real world applications out there that show that this is possible > > > right > > > > now > > > > > > [ with OSGi you can even mix versions of the same web-app in the same > > > > process ] > > > > > > that being said, developers should always remember to close resources > > > when > > > > done > > > > with them - and if you do happen to find a leak, be aware of the > usual > > > > suspects like > > > > logging, but back it up with facts (take a series of heapdumps, use > > > analysis > > > > tools) > > > > > > nothing's worse than a finger-pointing session when working on a > > > potential > > > > CritSit > > > > > > Dhanji. > > > > -- > > 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 -~----------~----~----~----~------~----~------~--~---
