ViewComponent memory leak?

[johnp...@googlemail.com]

Hi,

We have our own ViewComponent which inherits from the
ViewComponentEx. We have noticed our asp_net.exe memory usage
creeping up over a period of time whilst a site is live. We have
removed all usages of the viewcomponent and the memory usage stops
rising. We've also gone as far as having an empty Render function in
our viewcomponent and the memory usage keeps rising.

Other things we tried include using the GridComponent and the memory
still rises.

We are using the Castle, Rhino, NHibernate trunk combo.

Has anyone else noticed this ever?

John

[Ken Egozi]

are you also using Windsor integration?

--
Ken Egozi.
http://www.kenegozi.com/blog
http://www.delver.com
http://www.musicglue.com
http://www.castleproject.org
http://www.gotfriends.co.il

[Ben Lovell]

Can't say I've ever noticed this in the many apps I've worked on. Are your components being resolved through Windsor? Are they holding onto resources?

Ben
http://benl.wordpress.com/

[johnp...@googlemail.com]

Sorry forgot to add about Windsor. Yes we are using Windsor
integration.

We are also using the following Windsor.boo configuration

import System.Reflection
import Castle.MonoRail.Framework
import Castle.MonoRail.WindsorExtension
import Rhino.Commons.ForTesting from Rhino.Commons.NHibernate
import Rhino.Commons.ForTesting from Rhino.Commons.ActiveRecord

Facility("monorail", MonoRailFacility)

webAsm = Assembly.Load("SJP.Medical.Web")
viewCompsAsm = Assembly.Load("Castle.MonoRail.ViewComponents")
activeRecordAsm = (Assembly.Load("SJP.Medical.Models"),Assembly.Load
("CMSModels"))

for type in webAsm.GetTypes():
if typeof(Controller).IsAssignableFrom(type):
Component(type.Name, type)

for type in viewCompsAsm.GetTypes():
if typeof(ViewComponent).IsAssignableFrom(type):
Component(type.Name, type)


Component("active_record_repository", IRepository, ARRepository)
Component("active_record_unit_of_work",
IUnitOfWorkFactory,
ActiveRecordUnitOfWorkFactory,
assemblies: activeRecordAsm)

On Dec 19, 4:32 pm, "Ben Lovell" <benjamin.lov...@gmail.com> wrote:
> Can't say I've ever noticed this in the many apps I've worked on. Are your
> components being resolved through Windsor? Are they holding onto resources?
>

> Benhttp://benl.wordpress.com/
>
> On Fri, Dec 19, 2008 at 4:25 PM, johnpoll...@googlemail.com <

[Victor Kornov]

http://weblogs.asp.net/stefansedich/archive/2008/11/05/avoid-memory-leaks-when-using-windsor-and-not-releasing-objects.aspx

[johnp...@googlemail.com]

Just a thought, but I am inheriting the UnitOfWorkApplication in my
Global.asax. I'm not thinking this is the problem, but we do have to
force the UnitOfWork to start in the Application_Start as we need it
running for a custom urlrewriter we have.

We do dispose of the UnitOfWork.

On Dec 19, 4:51 pm, "johnpoll...@googlemail.com"

[Ken Egozi]

dispose != release

[James Curran]

On Fri, Dec 19, 2008 at 11:25 AM, johnp...@googlemail.com
<johnp...@googlemail.com> wrote:
> We have our own ViewComponent which inherits from the
> ViewComponentEx.

Looking over ViewCompoentEx to fnd possible trouble points:

(I guess this is part of the mixed blessing of open-source --- the
only times you learn that someone is actually using your code is when
they have a problem with it)

- Logger property - I don't even remember adding this, so I'm sure I
never got what I planned for it working, but the code looks
straight-forward enough.

- RenderComponent - Here I was just integrating Joey Beninghove's
code, so there could be a hidden problem in his code, or I could have
screwed something up while refactoring it.

- GetSectionText() - This has the best potenial for causing a
problem, since it's most likely to be used than the other two. This
has a StringWriter that probably should have been wrapped in the
using() block. I'm not sure if that could cause the problem you are
seeing, but I've just committed the fixed version.

--
Truth,
James

[hammett]

Two things: which view engine and are you using windsor _integration_
with monorail? Also which version?

--
Cheers,
hammett
http://hammett.castleproject.org/

[johnp...@googlemail.com]

The view engine we are using is Brail. Yes we are using Windsor
Integration. The version we are using is the latest trunks from
Castle, Rhino and NHibernate (well a build from Wednesday).

On Dec 19, 10:53 pm, hammett <hamm...@gmail.com> wrote:
> Two things: which view engine and are you using windsor _integration_
> with monorail? Also which version?
>

> On Fri, Dec 19, 2008 at 8:25 AM, johnpoll...@googlemail.com

[johnp...@googlemail.com]

Thanks for this James.

Not in the office until tomorrow, but will give that a try then.

John

On Dec 19, 7:54 pm, "James Curran" <james.cur...@gmail.com> wrote:
> On Fri, Dec 19, 2008 at 11:25 AM, johnpoll...@googlemail.com

[johnp...@googlemail.com]

I took Victor's advice and added the NoTrackingReleasePolicy which
appears to have fixed the memory leak. I may well post the issue on
the Rhino group and see what they say. It seems linked to the
UnitOfWorkApplication.

On Dec 19, 4:56 pm, "Victor Kornov" <wee...@gmail.com> wrote:
> http://weblogs.asp.net/stefansedich/archive/2008/11/05/avoid-memory-l...
>
> On Fri, Dec 19, 2008 at 7:51 PM, johnpoll...@googlemail.com <

[codemonkey]

Yeah I came across this issue as well, from what I understand you
should release your components from the container when you are done
with them.

container.Release(item), this will ensure proper release of items, the
container keeps track of resolved items in order to handle decommision
property, this post has some more information:

http://stackoverflow.com/questions/85183/windsor-container-how-to-force-dispose-of-an-object

AllComponentsReleasePolicy is the default IIRC which states "track all
components to enforce correct disposal upon the MicroKernel instance
disposal", not in my case I store my container for the lifecycle of my
web app, as you resolve, you can step through the code and you will
see that it keeps a reference to your resolved object internally,
hence objects hanging around and causing the memory leak.

I found using NoTrackingReleasePolicy to work fine for my purpose but
I am not aware of any negative implications of doing this.



Cheers
Stefan

On Dec 22, 7:56 pm, "johnpoll...@googlemail.com"

<johnpoll...@googlemail.com> wrote:
> I took Victor's advice and added the NoTrackingReleasePolicy which

> appears to have fixed thememoryleak.  I may well post the issue on

[hammett]

I bet the problem lies on the new implementation for the burden stuff.
Will try to fix it during the holidays.

[hammett]

The side effects is that you might have disposable components that are
not being disposed by the container.

[Germán Schuager]

Don't know if this is the case, but I've noticed that after the
component burden implementation the container doesn't release
references to transient components:

http://support.castleproject.org/projects/IOC/issues/view/IOC-ISSUE-132

On Dec 22, 4:01 pm, hammett <hamm...@gmail.com> wrote:
> I bet the problem lies on the new implementation for the burden stuff.
> Will try to fix it during the holidays.
>

> On Mon, Dec 22, 2008 at 2:56 AM, johnpoll...@googlemail.com

[hammett]

Your code should include a call to container.Release

That being said, the burden impl should be optimized to only hold a
chain (and references) if somewhere in the graph there's a disposable
type, which is something I'm planning to add.