RE: [openeverything] Memory Leak using Castle Windsor with OpenRasta and Disposable sub-dependencies

[Sebastien Lambla]

The current handler is in ICommContext.PipelineData, you can get that from castle itself. After that, calling the release on the handler in the method you talk about should work.

That said, I simply don't implement IDisposable on stuff that goes through castle, it is evil.

I have a much much nicer design for OW / OR3 that uses a simpler concept of scopes. Ah if I had all the time in the world to code :)

---

From: openevery...@googlegroups.com [openevery...@googlegroups.com] on behalf of SimonT [simonth...@hotmail.com]
Sent: 02 July 2012 15:13
To: openevery...@googlegroups.com
Subject: [openeverything] Memory Leak using Castle Windsor with OpenRasta and Disposable sub-dependencies

We have recently encountered a memory leak in an OpenRasta service that uses Castle Windsor for DI. We have tracked the issue down to a new dependency that implements IDisposable. When this new dependency is introduced, we find that the top level Handler is retained in memory as a 'live' reference by Castle and memory goes up and up until the service throws OOM exceptions

It seems to be a well documented concept that castle will track components that need disposing and that they must be explicitly released - see. e.g.

http://stackoverflow.com/questions/3334209/castle-windsor-do-i-have-to-release-singleton-or-non-disposable-transient-obje 

I suspect that the solution would be to call container.Release(handler) at an appropriate point but I'm not clear where that would be. IDependencyResolver.HandleIncomingRequestProcessed() seems to be a candidate, but I'm not clear how to get a reference to the current executing handler. An interceptor might be another option.

Anyone encountered (and solved?) similar issues.

 

[SimonT]

Thanks for that. I'd tend to agree re: Disposable and we have gotten away with it for a long time. It is particularly annoying since the dependency is actually Singleton, which shouldn't really need releasing by the container

A couple of other things to add:

We seem to be able to work around the handler issue by pre-installing the Handlers as PerWebRequest (allows CW to call release on request end..) - e.g. 

container.Register(

AllTypes

.FromAssembly(Assembly.GetExecutingAssembly())

.BasedOn<IOpenRastaHandler>()

.Configure(c => c.LifeStyle.Is(LifestyleType.PerWebRequest))

.WithService.Self());

We found a similar issue with a new OperationInterceptor with depended on the same thing as the handler which we have resolved by  pre-installing IOperationInterceptorProvider (the problematic transient component) 

container.Register(

Component.For<IOperationInterceptorProvider>()

.ImplementedBy<SystemAndAttributesOperationInterceptorProvider>()

.LifeStyle.PerWebRequest);

Does this seem acceptable as a work around?

On Tuesday, July 3, 2012 4:07:44 PM UTC+1, SerialSeb wrote:

The current handler is in ICommContext.PipelineData, you can get that from castle itself. After that, calling the release on the handler in the method you talk about should work.

That said, I simply don't implement IDisposable on stuff that goes through castle, it is evil.

I have a much much nicer design for OW / OR3 that uses a simpler concept of scopes. Ah if I had all the time in the world to code :)

---

From: openeverything-dev@googlegroups.com [openeverything-dev@googlegroups.com] on behalf of SimonT [simonth...@hotmail.com]

Sent: 02 July 2012 15:13

To: openeverything-dev@googlegroups.com

Subject: [openeverything] Memory Leak using Castle Windsor with OpenRasta and Disposable sub-dependencies