Controller has DisposeA lot of stuff has dispose that shouldn't have. We shouldn't have a problem like that by default.
On Wed, Mar 4, 2009 at 12:21 PM, Craig Neuwirt <[email protected]> wrote: > If you forget to close an Open File in your app, its remain locked, but you > usually discover that during testing and fix it. If you don't need any > releasing, don't implement IDisposable and it won't be tracked > > On Wed, Mar 4, 2009 at 2:16 PM, Ayende Rahien <[email protected]> wrote: > >> The problem is that people don't call release. >> Then they have a memory leak because of this behavior. >> - Show quoted text - >> >> >> On Wed, Mar 4, 2009 at 12:07 PM, hammett <[email protected]> wrote: >> >>> >>> As much as any disposable type expects to be disposed. As Craig >>> pointed out, this should happen on the bootstraping code, not >>> throughout the application. I dont see the problem. But I can be >>> convinced otherwise. >>> >>> >>> Cheers, >>> hammett >>> http://hammett.castleproject.org/ >>> Sent from: Vancouver British Columbia Canada. >>> >>> >>> On Wed, Mar 4, 2009 at 12:00 PM, Ayende Rahien <[email protected]> >>> wrote: >>> > _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 >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>> >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >>> >>> >> >>> >> >>> >> >>> > >>> > >>> > > >>> > >>> >>> >>> >> - Show quoted text - >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
