This behavior is supported by default. We dont share registrations of component as Autofac does, though. Disposing a child container will dispose the components instances there.
Cheers, hammett http://hammett.castleproject.org/ Sent from: Redmond Washington United States. On Wed, Mar 4, 2009 at 12:08 PM, Julian Birch <[email protected]> wrote: > I think part of the problem is the call to Release. Separating out > registration and containers at the interface level would allow you to create > multiple containers which could Release upon disposal of the container. > Not sure if that's clear. You're probably aware of AutoFac's approach. I > do think it makes these questions simpler. You build the registration. You > create the container, and when you dispose of the container everything gets > thrown away. You have multiple containers for multiple scopes (Singletons > are a bit of a problem, but not insurmountable.). > I've written a facility that implements this behaviour, within the > limitations of working within the existing model. It's not for everyone, > but it does do stuff like proxy dispose so that it calls release. > Julian Birch > > > 2009/3/4 Ayende Rahien <[email protected]> >> >> _having_ to release means that we are putting the onus on the developer to >> do the right thing. >> I think that this is a mistake to do so by default. Especially since we >> generally don't need this in .Net >> If we do need it, we can activate the feature, and >> assume responsibility for its operation. >> >> On Wed, Mar 4, 2009 at 11:47 AM, Craig Neuwirt <[email protected]> wrote: >>> >>> yes, but generally just the root object and the component burden does the >>> rest which is very important service >>> >>> On Wed, Mar 4, 2009 at 1:36 PM, Ayende Rahien <[email protected]> wrote: >>>> >>>> The problem is that this means that you have to release. >>>> >>>> On Wed, Mar 4, 2009 at 11:18 AM, Craig Neuwirt <[email protected]> >>>> wrote: >>>>> >>>>> Dispose is just one type of decomission. There are other that get >>>>> added dynamically by facilities which need to be applied >>>>> when components are >>>>> released. I think this behavior is important by default >>>>> >>>>> On Wed, Mar 4, 2009 at 12:51 PM, Ayende Rahien <[email protected]> >>>>> wrote: >>>>>> >>>>>> It seems that a lot of people are surprised by this behavior, I think >>>>>> it would be wiser to no track components by default. >>>>>> Thoughts? >>>>>> >>>>>> On Wed, Mar 4, 2009 at 8:54 AM, kurtharriger <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> I don't understand why this isn't the default setting either. IMHO, >>>>>>> Transient objects should not be tracked by default. >>>>>>> >>>>>>> As many several have noticed the issues arising tracking transient >>>>>>> objects for dispose is greater then the risk of not calling dispose >>>>>>> at >>>>>>> all (and unless the object holds unmanaged resources, dispose is not >>>>>>> all that necessary anyway). A disposable component that *must be >>>>>>> disposed* should also implement a finalizer and that doesn't change >>>>>>> by >>>>>>> using a container since there is no guarantee dispose will be called >>>>>>> on container either. Since release accepts the object to dispose as a >>>>>>> parameter there isn't any reason to track it, if object is not >>>>>>> tracked >>>>>>> then assume it is transient and call dispose if implemented. >>>>>>> >>>>>>> - Kurt >>>>>>> >>>>>>> >>>>>>> On Mar 3, 4:57 pm, Andrew Smith <[email protected]> wrote: >>>>>>> > Yea, I was worried about negative effects of this also. You don't >>>>>>> > get >>>>>>> > something for nothing, right? The only mention I've seen so far is >>>>>>> > a comment >>>>>>> > from hammett in the another post to this group ("ViewComponent >>>>>>> > memory >>>>>>> > leak"): >>>>>>> > >>>>>>> > "The side effects is that you might have disposable components that >>>>>>> > are >>>>>>> > not being disposed by the container" >>>>>>> > >>>>>>> > In my case I know I don't have any disposable components involved, >>>>>>> > so after >>>>>>> > some proper testing, I'll be applying the 'fix' to my server >>>>>>> > >>>>>>> > On Tue, Mar 3, 2009 at 11:45 PM, Stefan Sedich >>>>>>> > <[email protected]>wrote: >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > > Excellent glad I could help. But I would look into releasing your >>>>>>> > > objects properly, not sure maybe someone can comment on negative >>>>>>> > > impacts of using NoTrack policy. >>>>>>> > >>>>>>> > > Cheers >>>>>>> > >>>>>>> > > On Wed, Mar 4, 2009 at 9:43 AM, Andrew Smith <[email protected]> >>>>>>> > > wrote: >>>>>>> > > > just changed the policy and re-ran a local stress test. >>>>>>> > > > Immediate >>>>>>> > > > improvement. Previous test ended with memory usage of ~200MB, >>>>>>> > > > this time >>>>>>> > > > round 70MB >>>>>>> > > > thanks again! >>>>>>> > >>>>>>> > > > On Tue, Mar 3, 2009 at 11:37 PM, Stefan Sedich >>>>>>> > > > <[email protected]> >>>>>>> > > > wrote: >>>>>>> > >>>>>>> > > >> No problems, >>>>>>> > >>>>>>> > > >> Something that caught me too, I knew a few people that were >>>>>>> > > >> not aware >>>>>>> > > >> and they had never stress tested their apps or realised it was >>>>>>> > > >> resetting (dangerous). I am glad I profile my stuff before >>>>>>> > > >> putting it >>>>>>> > > >> anywhere near production. I guess releasing is the way proper >>>>>>> > > >> way to >>>>>>> > > >> handle things, but I have been naughty and just used >>>>>>> > > >> NoTracking. >>>>>>> > >>>>>>> > > >> Cheers >>>>>>> > >>>>>>> > > >> On Wed, Mar 4, 2009 at 9:33 AM, Andrew Smith >>>>>>> > > >> <[email protected]> >>>>>>> > > >> wrote: >>>>>>> > > >> > Hi Stefan, >>>>>>> > > >> > you know as soon as I posted that, of course I came across >>>>>>> > > >> > details on >>>>>>> > > >> > this >>>>>>> > > >> > issue. In fact your very blog post. In all the time I've >>>>>>> > > >> > used castle, >>>>>>> > > I >>>>>>> > > >> > never realised I was expected to explicitly release a >>>>>>> > > >> > transient >>>>>>> > > >> > component. >>>>>>> > > >> > By the sounds of it, I'm sure that will be the cause as I'm >>>>>>> > > >> > using >>>>>>> > > >> > windsor >>>>>>> > > >> > integration heavily and can easily repro the issue with a >>>>>>> > > >> > local stress >>>>>>> > > >> > test. >>>>>>> > > >> > Thanks for the info >>>>>>> > > >> > Cheers, >>>>>>> > > >> > Andrew >>>>>>> > >>>>>>> > > >> > On Tue, Mar 3, 2009 at 11:24 PM, Stefan Sedich < >>>>>>> > > [email protected]> >>>>>>> > > >> > wrote: >>>>>>> > >>>>>>> > > >> >> Andrew, >>>>>>> > >>>>>>> > > >> >> I have built a few simmilar sounding shop fronts, with >>>>>>> > > >> >> medium load >>>>>>> > > and >>>>>>> > > >> >> have not had issues with memory leaks with the app pools >>>>>>> > > >> >> running >>>>>>> > > solid >>>>>>> > > >> >> until their nightly reset. >>>>>>> > >>>>>>> > > >> >> If you hit your site with a web stress testing tool do you >>>>>>> > > >> >> see the >>>>>>> > > >> >> memory continue to climb until app pool reset? If this is >>>>>>> > > >> >> the case it >>>>>>> > > >> >> is possible you have a memory leak. >>>>>>> > >>>>>>> > > >> >> I would suggest getting a tool like ANTS profiler to see if >>>>>>> > > >> >> you can >>>>>>> > > >> >> track down any memory leaks in your application and then go >>>>>>> > > >> >> from >>>>>>> > > >> >> there. I would say from what I have seen in my apps ~200MB >>>>>>> > > >> >> seems >>>>>>> > > >> >> reasonable depending on what it is doing. >>>>>>> > >>>>>>> > > >> >> In my last project I had similar issues you describe. In my >>>>>>> > > >> >> case I >>>>>>> > > was >>>>>>> > > >> >> using Windsor and not releasing my components from the >>>>>>> > > >> >> container when >>>>>>> > > >> >> I was done with them. In my case I decided to not release >>>>>>> > > >> >> my objects >>>>>>> > > >> >> and use the NoTrackingReleasePolicy instead, as this was >>>>>>> > > >> >> fine for my >>>>>>> > > >> >> needs and removed the leak that I had. >>>>>>> > >>>>>>> > > >> >> I have blogged about this here: >>>>>>> > >>>>>>> > >>>>>>> > > >http://weblogs.asp.net/stefansedich/archive/2008/11/05/avoid-memory-l... >>>>>>> > >>>>>>> > > >> >> Cheers >>>>>>> > > >> >> Stefan >>>>>>> > >>>>>>> > > >> >> On Wed, Mar 4, 2009 at 9:04 AM, Andrew <[email protected]> >>>>>>> > > >> >> wrote: >>>>>>> > >>>>>>> > > >> >> > I've just launched an e-commerce website based on >>>>>>> > > >> >> > Monorail and >>>>>>> > > using >>>>>>> > > >> >> > ActiveRecord. It's a replacement of a previous PHP >>>>>>> > > >> >> > solution and we >>>>>>> > > >> >> > have on average about 20 - 30 concurrent users at any >>>>>>> > > >> >> > given time. >>>>>>> > > I'm >>>>>>> > > >> >> > also running an admin site in the same application pool. >>>>>>> > >>>>>>> > > >> >> > My issue is to do with memory usage. I'm running on a >>>>>>> > > >> >> > 1GB VPS box >>>>>>> > > >> >> > (also hosting a SQL Server DB on same machine). I've >>>>>>> > > >> >> > limited SQL >>>>>>> > > >> >> > Server to 200MB and my IIS6 worker process to 400MB. >>>>>>> > > >> >> > However, even >>>>>>> > > >> >> > pre- >>>>>>> > > >> >> > release when testing with 1 or 2 users the memory usage >>>>>>> > > >> >> > would >>>>>>> > > easily >>>>>>> > > >> >> > sit around the 300MB mark. Now with the real load, I'm >>>>>>> > > >> >> > seeing the >>>>>>> > > >> >> > application pool recycle approx every 40 mins (normally >>>>>>> > > >> >> > should only >>>>>>> > > >> >> > recycle at 3am). I'm using the ASP.Net state service so >>>>>>> > > >> >> > session >>>>>>> > > >> >> > details are preserved but still, I'm concerned >>>>>>> > >>>>>>> > > >> >> > As I said, it's an e-commerce site so there's the usual >>>>>>> > > >> >> > shop >>>>>>> > > stuff: >>>>>>> > > >> >> > lots of nice pics, searches, checkout and a bit of 2nd >>>>>>> > > >> >> > level >>>>>>> > > caching >>>>>>> > > >> >> > for things such as categories (max 200 categories), >>>>>>> > > >> >> > countries, >>>>>>> > > rates >>>>>>> > > >> >> > etc. Really not that much is cached and mem usage was >>>>>>> > > >> >> > high before >>>>>>> > > we >>>>>>> > > >> >> > fully optimised the site. I've been careful to have the >>>>>>> > > >> >> > SQL >>>>>>> > > profiler >>>>>>> > > >> >> > beside me as we were testing the app, so I'm confident >>>>>>> > > >> >> > that I don't >>>>>>> > > >> >> > have N+1s all over the place. Oh, and I'm using standard >>>>>>> > > session-per- >>>>>>> > > >> >> > request model using Ayende's UOW stuff >>>>>>> > >>>>>>> > > >> >> > I guess what I'm asking is: Is that level of memory >>>>>>> > > >> >> > usage expected >>>>>>> > > >> >> > for that type of site? I would love to hear back from >>>>>>> > > >> >> > anyone who >>>>>>> > > has >>>>>>> > > >> >> > launched a similar type of site. >>>>>>> > >>>>>>> > > >> >> > I did see a previous post about this, but they are >>>>>>> > > >> >> > talking around >>>>>>> > > >> >> > the >>>>>>> > > >> >> > 200MB mark, so I'm wondering what on earth I'm doing >>>>>>> > > >> >> > wrong! >>>>>>> > >>>>>>> > > >> >> > There is the option of shelling out more cash and go to a >>>>>>> > > >> >> > 2GB VPS >>>>>>> > > >> >> > box, >>>>>>> > > >> >> > but I'd rather not have to.... >>>>>>> > >>>>>>> > > >> >> > cheers >>>>>>> > >>>>>>> > > >> >> -- >>>>>>> > > >> >> Stefan Sedich >>>>>>> > > >> >> Software Developer >>>>>>> > > >> >>http://weblogs.asp.net/stefansedich >>>>>>> > >>>>>>> > > >> -- >>>>>>> > > >> Stefan Sedich >>>>>>> > > >> Software Developer >>>>>>> > > >>http://weblogs.asp.net/stefansedich >>>>>>> > >>>>>>> > > -- >>>>>>> > > Stefan Sedich >>>>>>> > > Software Developer >>>>>>> > >http://weblogs.asp.net/stefansedich >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" 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/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
