Finalizer leaking memory is one thing, but what I find even more suspicious is that warp-servlet is not reseting rootInjector to null on shutdown. This doesn't make sense in light of what I see in the source-code.
The only way I will be able to track this down is if I have the source- code and matching binary builds for guice and warp-servlet. Right now I'm running off trunk builds of both guice and warp-servlet without corresponding sources. I don't think either of these builds have been tagged in the repositories. I see contextDestroyed() being invoked in my own code just fine but I have no way of knowing whether the same is true for warp-servlet's filter. I'd love to be able to add some println()s and rebuild the code on my end. Gili On Nov 26, 9:29 pm, Gili <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
