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