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). 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
