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