Am I understanding this correctly? The complaint is that prior to release tracking changes, users were adding transient disposable components to the container, resolving them, and never calling dispose. There was no true memory leak because when they would go out of scope they would eventually be GC'd.
Release tracking is now holding a reference to the component so it is never GC'd and this is bringing to user's attention that they are improperly using disposable components by not disposing of them when they are done. And the request is that we either revert back to the way things were done before so users can continue to improperly use disposable components or add make the implementation optional or somehow indicate to users that this feature is working by design and they need to use it properly. I'm surprised at the statement that this puts the onus on the developer to do the right thing. If you don't want to do the right thing that's fine, just buy more ram or reboot your app pool every two minutes. Why is this any different than putting the onus on the developer to dispose of a db connection? Or as Craig said a file handle? There is no requirement to do this but your app will crash when you exceed max handles. On Thu, Mar 5, 2009 at 10:19 AM, João Bragança <[email protected]> wrote: > > You could just fix the problem by posting this thread on the website! > After reading it I realized my memory leak was probably caused by me > not explicitly releasing transient components after I was done. Wasn't > an issue before the component burden fix. > > What about approaching this a different way? Something like > IKernelStatistics... hooks into the kernel events and keeps a > breakdown of components by lifestyle and how many have yet to be > released. A developer can put a breakpoint right before kernel.Dispose > or you could have optional logging. > > On Mar 4, 2:42 pm, hammett <[email protected]> wrote: >> Like I said, I wont stand for this one. I stated what I believe is the >> right default behavior. >> >> I rest my case. >> >> On Wed, Mar 4, 2009 at 2:38 PM, Ayende Rahien <[email protected]> wrote: >> > The problem is that the correct usage pattern put a lot of onus on the >> > user. >> > I mean, it is very easy to avoid leaking memory in C++, just free anything >> > that you allocate. >> > Nevertheless, this seems to be >> > common: http://en.wikipedia.org/wiki/Memory_leak >> >> > On Wed, Mar 4, 2009 at 2:35 PM, hammett <[email protected]> wrote: >> >> >> I honestly don't get it - and believe me, I'm trying. >> >> >> In the very "getting started" article I mention the correct usage pattern: >> >>http://www.castleproject.org/container/gettingstarted/part1/code.html >> >> >> Search for container+release and you'll get more hits >> >> >>http://www.google.com/custom?q=container+release&sa=Google+Search&cof... >> >> >> Your usage pattern seems to beg for container hierarchy anyway. >> >> >> I'm not standing in front of this issue, though. If you - community - >> >> think this is how it's supposed to be, I'm fine - meritocracy: i'm not >> >> doing much for the project nowadays, so I wont make your life harder >> >> :-) >> >> >> But I read some divergence of opinions on this thread. >> >> >> On Wed, Mar 4, 2009 at 1:51 PM, Victor Kornov <[email protected]> wrote: >> >> > I don't want to make trade offs ;) >> >> > What I'm trying to say is this right & deterministic behavior leads to >> >> > unexpected, not obvious & mostly undiscovered by devs issues like memory >> >> > leaks. >> >> > Isn't there a way not to educate everyone on your way of doing things, >> >> > but >> >> > to slap them in the face when they do it wrong? ;) > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
