Revisit tracking transient services for disposal

[khellang]

Tracking transient objects for disposal is a pretty bad practice and will almost always lead to memory leaks. Even if it's tracked in a scoped provider, it'll be kept around for longer than it needs to, at a minimum.

This is why containers like SimpleInjector and StructureMap (and probably others as well) don't track transient disposables. SimpleInjector even has a diagnostic warning about this.

In order to comply with the MS.Ext.DI specs, StructureMap had to introduce a way to opt-in to track transients for disposal, which sucks.

I've already seen several reports on severe memory leaks because of this in the wild. Here's the latest example: https://gitter.im/aspnet/Home?at=57ff6e91891a530163074f94

Hey guys ... anybody here that has some experience with the .NET Core DI implementation? I run into a memory leak because a type I registered with services.AddTransient<IMyType, MyType>() does not get garbage collected. With VS memory diagnostics I found out that a List<IDisposable> within the ServiceProvider class holds references to all instances of it. So it might be a misconception about how it should work on my side ... but I think that ServiceProvider should not hold references to types I registered as transient. Am I wrong about that?

I also suspect there are other, less severe memory leaks around, that people haven't noticed yet or worked around.

What can be done about this? The least breaking change I can see is add a Release method somewhere that can be used to explicitly evict specific instances from tracking, but ideally, this behavior should be removed altogether and throw if a transient disposable is registered.

// @davidfowl @pakrym @tillig @alexmg @nblumhardt @seesharper @jeremydmiller @dotnetjunkie

[khellang]

Oh, I just noticed this is being "thought about" for a future version. 👍 (#433 (comment)) I'll keep this open for tracking this specific issue.

[nblumhardt]

Watching this thread with interest - spent a long time on this topic over the years :-)

Tracking transient objects for disposal is a pretty bad practice and will almost always lead to memory leaks.

This statement may not be the best starting point. It's one of those cases where "the way you've always done it" seems like the most logical way, whichever camp you're in. The alternative point of view goes something like - how do you do release resources deterministically in a loosely-coupled system if your IoC container can't/won't do it?

There are good arguments for either position; I can't see any value coming from a debate on the merits of one tactic or the other. I know that's not the intention of the ticket, but perhaps this will be easier to work through if we frame the discussion more carefully as:

• Some developers want their IoC container to track transient resources
• Some developers don't
• How can the framework support both styles
  • while meeting it's own functional requirements reliably, and
  • without adding complexity/confusion/surprises for users like the one mentioned above?

Or something along those lines. If that sounds close to the mark, getting a clear write-up of what the framework needs in terms of resource management, and what the desired user experience is, would be great next-steps.

[khellang]

The alternative point of view goes something like - how do you do release resources deterministically in a loosely-coupled system if your IoC container can't/won't do it?

I'm not sure I see how you could properly resolve transient instances without doing a call to IServiceProvider.GetService<TTransientService>. If you resolve them in any other way, i.e. in the constructor of a scoped or singleton service, you already have an issue with captive dependencies. This scenario will throw in v1.1, see #430 (comment).

When you do the call to IServiceProvider.GetService<TTransientService>, and something in the graph is IDisposable, TTransientService should also be IDisposable (it's viral). It's the the callers responsibility to properly dispose the service when done with it.

[davidfowl]

A compromise might be to only track transient disposable objects in scopes outside of the root scope or make it a setting like scope validation.

[ipjohnson]

@davidfowl Are you suggesting that the child scopes should act differently from parent scope?

I happen to fall in line with how Autofac handles this by default transients are tracked unless otherwise configured. This seems to give the best of both worlds auto disposal if you want it, turn it off when you don't.

One of the upsides for transient tracking by the container is that the interface you request doesn't have to implement IDisposable. For example the interface generated for WCF proxies don't implement IDisposable even though the generated proxy class implements the IDisposable interface.

[nvivo]

Commenting here just to say I'm also affected by memory leaks due to this issue, where EF contexts are never released from memory when added using AddTransient.

Preferences aside, I'm not sure how the provider would track any disposables without a scope. It simply holds the instances forever and never knows when to dispose them.

[jbogard]

@nvivo Side question - why are you registering EF contexts as transient? Shouldn't they be scoped?

[davidfowl]

@nvivo not just that but why not just make a scoped service provider and resolve from that. If we do anything here it would be adding an options to turn the tracking off. There's a question as to whether we should turn it off just for scopes or all up. We haven't made a decision to do anything just yet though as turning it off by default would be a massive breaking change.

[ipjohnson]

@davidfowl I can see where you are coming from with the idea of having the root scope act differently from a child scope but that to seems more confusing. Maybe it's just me but some classes dispose their transient dependencies while others don't all because they are resolved from a different scope sounds scary (what if you decided to start resolving it in a different scope then you have to change code?)

Turning it on/off for a whole container instance seems like a reasonable compromise between the two sides as @nblumhardt said there are developers that want transient track and some that don't.

Maybe to help address these "Memory leaks" it's a matter of disseminating the pattern to create a scoped service provider and resolve from it (maybe it's out there and I haven't run into it as I haven't looked).

[nvivo]

@jbogard I'm using the DI container with akka actors inside a windows service. There is no natural scope to tie it to. Some actors live forever, and I sometimes want to release the entire set I was working with and get a clean context inside the same actor. For long running services, it's much simpler to have transient scopes.

@davidfowl I guess I can workaround with scopes. It's not as clean though. Correct me if I'm wrong, but I'd have to change from:

using (var ctx = provider.GetRequiredService<DataContext>()) {
	...
}

to:

using (var scope = rootProvider.CreateScope()) {
	var ctx = scope.ServiceProvider.GetRequiredService<DataContext>();
	...
}

As for the breaking change, unless I'm missing something, if you just stop tracking disposables at the root level, the worst thing that could happen is that sometimes resources won't be freed. Currently what happens is that resources are never freed, doesn't matter if we call Dispose or not. This is a huge problem.

If changes were made to stop tracking disposables at the root level, ASP.NET shouldn't be affected as it's always scoped to requests. Or am I missing something?

Anyway, I strongly believe that the leak shouldn't happen. Either it stops tracking the disposable at the root level or it prevents us from instantiating transient disposables at the root level. The first option being much simpler and cleaner.

[nvivo]

@ipjohnson I agree a documented pattern would be a good idea, but I don't think it would solve the actual problem. It's not like the leak happens on a very obscure case. GetService is the only thing you can do with a provider, it shouldn't force a leak by design.

[ipjohnson]

@nvivo I'm confused how exactly does david's suggestion not solve the problem?

To david's point if you stop disposing transients then existing code that depends on this really will have a memory leak not just trapped transients like what you have now.

[nvivo]

@ipjohnson I guess we're discussing different things or you didn't notice the current problem.

First: scopes actually solve the problem, but create another. My code suddenly needs to be aware it needs a different scope and hard code it. The issue IMO is that scopes should be something handled by the infrastructure, not hardcoded just to make disposables work. Disposables already have an interface for that. In my case, a windows service with long lived objects doesn't have any natural scope.

Second, you said:

Maybe it's just me but some classes dispose their transient dependencies while others don't all because they are resolved from a different scope sounds scary

This is exactly what is happening today. It's not a matter if I want the framework to handle it or not. Currently, using the container as intended, you can get instances that will never be released, by design. This shouldn't happen. We cannot say the root provider is exactly the same as a scoped provider because scoped providers can be disposed, but the root provider is a singleton, it makes no sense to destroy and create another. So, today the same interface provides different behavior.

An alternative to all of this is a Release/DisposeService method, so I could manually tell the provider to dispose of the instance for me in such cases. It would be the obj.Dispose() counterpart for DI. It wouldn't replace the tracking, it would simply force the disposal before disposing the provider.

[ipjohnson]

@nvivo I guess I look at it as multiple DI containers (autofac, this project, and grace to name three) do transient tracking and consider it a feature. The container was designed to operate this way and is inherently not a bug (you can disagree with the feature but it's not a bug).

"Currently, using the container as intended, you can get instances that will never be released, by design. "

Technically this is not true, the instance will most certainly be disposed when the scope that it's resolved from disposes. You are just choosing to resolve from the root scope and getting a behavior you didn't expect. Also it seems like one of the creators of the container is specifically telling you in this thread it was never intended for you to resolve disposable transients from the root scope.

To your point today you are correct to do what you want to do you have to make your class a bit smarter but is this really the common use case for this container? It seems to me the common use case is in a scope per request situation in AspNetCore, not calling GetService directly from the root scope to resolve disposable transients.

I'm all for making it a feature that can be turned on/off but the idea that transient tracking is completely wrong and needs to be removed completely seems to ignore a number of other very valid opinions and use cases.

[nvivo]

@ipjohnson Just to clarify, I didn't said the idea of transient tracking is wrong. What is wrong is to track the transient disposables in the root container and not allow me to release them. Since it's not possible to dispose the container, it's just holding references forever.

Technically this is not true, the instance will most certainly be disposed when the scope that it's resolved from disposes

This is unrealistic. In real world, you cannot destroy the root container without restarting your application. And even in ASP.NET you can access the root container and create memory leaks.

Honestly, I think creating a scope in code just to dispose a service is a bad solution. This is not making the class smarter, it's just adding boilerplace. If I need to remember to create and dispose a new scope, I can as well remember to dispose the instance directly.

Now, again, I'm not against tracking disposables or scopes. I'm just saying it's not enough. Those are two ways to handle lifecycles. Scopes work well with requests and such, and tracking works there as well. But another simple and more natural way is to call .Dispose() whenever I need, directly or indirectly through a Release/DisposeService method.

So, after considerations, I vote to make IServiceProvider as:

public interface IServiceProvider
{
	object GetService(Type serviceType);
	void DisposeService(object service);
}

DisposeService would look for that object in the _transientDisposables list, and if found, call Dispose() and remove it from there. This wouldn't require breaking any compatibility, can be used in any level and wouldn't change scopes or tracking in any way.

@davidfowl was this considered?