We Keep Coding

Memory leak in Xamarin Forms app when using DI in a Task

I am creating a Xamarin Forms application, and I am using the Xamarin Profiler to show that I have a memory leak. I have tracked the memory leak down to where it is happening, but I can't understand WHY it is happening.
I have a class (we will call it MyClass for now). And that class is using a Timer to call a service once every second. That service makes a REST call to retrieve a bunch of information, and then serializes the results back into an object....
MyClass:
public class MyClass : ContentPage
{
private readonly IMyService myService;
public MyClass() : base()
{
}
protected override async void OnAppearing()
{
StartTimer();
}
private void StartTimer()
{
Task.Run(async() =>
{
while(true)
{
myService = ((App)App.Current)
.serviceProvider
.GetRequiredService<IMyService>();
//--- everytime I call myService.GetSystemStatus(), my allocated memory continues to rise
MyResponse response = await myService.GetSystemStatus();
Device.BeginInvokeOnMainThread(() =>
{
// update the UI here...
});
await Task.Delay(1000);
}
});
}
}
MyService (Singleton):
public class MyService : IMyService
{
private readonly IMyHttpClientFactory httpClientFactory;
public MyService(IMyHttpClientFactory httpClientFactory)
{
this.httpClientFactory = httpClientFactory;
}
public async Task<MyResponse> GetSystemStatus()
{
return await httpClientFactory.Create().GetAsync<MyResponse>(
"http://example.com/api/status"
);
}
}
MyHttpClientFactory (Singleton):
public class MyHttpClientFactory : IMyHttpClientFactory
{
private readonly IServiceProvider _serviceProvider;
public MyHttpClientFactory(IServiceProvider serviceProvider)
{
_serviceProvider = serviceProvider;
}
public MyHttpClient Create()
{
return _serviceProvider.GetRequiredService<MyHttpClient>();
}
}
MyHttpClient:
public class MyHttpClient : IDisposable
{
private HttpClient _httpClient;
public MyHttpClient ()
{
_httpClient = new HttpClient();
_httpClient.Timeout = TimeSpan.FromSeconds(10);
}
public async Task<T> GetAsync<T>(string url) where T : new()
{
string s = await GetStringAsync(url);
return JsonConvert.DeserializeObject<T>(s);
}
public async Task<string> GetStringAsync(string url)
{
using (var response = await _httpClient.GetAsync(url))
{
response.EnsureSuccessStatusCode();
return await response.Content.ReadAsStringAsync();
}
}
}
My services are defined as follows:
public partial class App : Application
public ServiceProvider serviceProvider;
public App()
{
IServiceCollection services = new ServiceCollection();
ConfigureServices(services);
serviceProvider = services.BuildServiceProvider();
InitializeComponent();
}
private void ConfigureServices(IServiceCollection services)
{
services.AddHttpClient<MyHttpClient>("MyHttpClient", x =>
{
x.Timeout = TimeSpan.FromSeconds(5);
});
services.AddSingleton<IMyHttpClientFactory, MyHttpClientFactory>();
services.AddSingleton<IMyService, MyService>();
}
}
Best I can tell, the memory is going up because I am referencing the DI MyService inside a separate thread. But I am not sure if this is the reason or if there is something else that would be causing the leak?
Any advice would be greatly appreciated!!!
Thanks!

From what I understand from your code and your comments, it looks like you're looping by calling StartTimer() inside the Device.StartTimer() method.
According to the documentation, Device.StartTimer() is recurring and will occur every X seconds, depending of your interval parameter.
By removing the call to StartTimer() (the one between t.Dispose() and return false of MyClass.StartTimer, your code should work as expected and you will not create a new timer every x seconds

What could be the cause of the leak:
Your MyHttpClient class implements the IDisposable interface, yet the code to use an instance of this class is not leveraging the disposable nature of the object.
Even though the internal HttpClient instance is wrapped in a using statement, the MyHttpClient instance will not be disposed of as you would expect.
// from MyHttpClient class
public async Task<MyResponse> GetSystemStatus()
{
// no using statement here
return await httpClientFactory.Create().GetAsync<MyResponse>(
"http://example.com/api/status"
);
}
// should be:
public async Task<MyResponse> GetSystemStatus()
{
using (var client = await httpClientFactory.Create())
{
return await client.GetAsync<MyResponse>("http://example.com/api/status");
}
}
Another thing to try is to change the location of the resolution of the MyService instance to inside the Task since this is where it is used. This will allow the task to own the resource, and allow it to be collected when the task is complete.
private void StartTimer()
{
Device.StartTimer(TimeSpan.FromSeconds(1), () =>
{
Task t = Task.Run(async() =>
{
// resolve the service here
myService = ((App)App.Current)
.serviceProvider
.GetRequiredService<IMyService>();
MyResponse response = await myService.GetSystemStatus();
Device.BeginInvokeOnMainThread(() =>
{
// update the UI here...
});
});
t.Wait();
t.Dispose();
StartTimer();
return false;
});
}
A couple of additional observations of your code:
In your HttpClientFactory's Create() method, you are resolving an instance of your client from the DI container.
Your MyHttpClient class has a default constructor which means the resolution is not needed since there are no additional dependencies requiring DI support.
Your code could simply return a new MyHttpClient() instance from the Create() method without the need for DI.
Your MyHttpClient also implements the IMyHttpClient interface, but your factory returns the concrete type. This means you need to either remove the interface as unnecessary or change the return type to be the interface type since the interface is redundant unless it is used.

Thank you all for your answers....
I finally figured out the source of the memory leak.
The problem was that I was referencing "MyService" like this:
myService = ((App)App.Current)
.serviceProvider
.GetRequiredService<IMyService>();
The problem was that the serviceProvider object was a public property on my App. So each time I referenced the provider inside my loop, it was creating the leak.
To get around this, I added an abstract method to each of my pages that implemented MyClass to return the service correctly using DI. This has corrected my memory leak issue....
Thanks all for the help!

I don't think that your timer logic is the cause of the leak.
But in case it is useful to you, here is a clean way to do work periodically, yet if work takes a long time, avoid events "piling up".
Given await/async, no Timer is needed.
(There is an alternative solution that starts/stops a single System.Timers.Timer, but I won't go into that here.)
Replace StartTimer() declaration with the following:
/// <summary> Runs until keepRunning() returns false.
/// Delays by "msecDelay" AFTER finishing the previous loop's non-UI work. </summary>
private void StartTaskLoopWhileKeepRunning(Func<bool> keepRunning, int msecDelay = 250)
{
Task.Run(async () =>
{
while (keepRunning())
{
// Do non-UI work here.
// ... possibly slow work ...
Device.BeginInvokeOnMainThread(() =>
{
// NOTE: This work will run in parallel with the next delay.
// ... Do UI work here. ...
});
// Non-UI thread sleeps for msec.
await Task.Delay(msecDelay);
}
});
}

Issue when upgrading Autofac with async tasks and owned instances

I have an issue with Autofac after upgrading from 4.9.2 to 5.2 in my ASP.NET MVC application.
I make use of Func<Owned<T>> factory pattern in the Controller because an Controller Action starts a Long running Task and will run longer than the request exists. In that Task I am resolving other instances.
This worked fine in Autofac 4.9.2. But after upgrading to Autofac 5.2 the parent Lifetime scope (AutofacWebRequest) gets disposed and it not possible to resolve instances within the owned instance anymore.
Instances cannot be resolved and nested lifetimes cannot be created from this LifetimeScope as it (or one of its parent scopes) has already been disposed.
Is there something I can do to work around this or is there a best practice?
Controller Code:
private readonly Func<Owned<IBusinessLogic>> _businessLogicFactory;
public ActionResult Index()
{
var businessLogic = _businessLogicFactory();
var unitOfWorkFactory = _unitOfWorkFactory;
Task.Run(() =>
{
System.Threading.Thread.Sleep(5000); // Sleep simulates that it may take some time until other instances are resolved
using (businessLogic)
{
var task = businessLogic.Value.DoHardBusinessAsync();
task.Wait();
}
});
return View();
}
Business Logic Code (also using a factory):
public class BusinessLogic : IBusinessLogic
{
private readonly Func<Owned<OtherBusinessLogic>> _otherBusinessLogicFactory;
public BusinessLogic(Func<Owned<OtherBusinessLogic>> otherBusinessLogicFactory)
{
_otherBusinessLogicFactory = otherBusinessLogicFactory;
}
public async Task DoHardBusinessAsync()
{
using (var otherBusiness = _otherBusinessLogicFactory())
{
await otherBusiness.Value.DoHardBusinessAsync();
}
}
}

You could try to create a new lifetime scope that is independent of the request scope to be used with your long running task like so
Task.Run(() =>
{
using (var scope = container.BeginLifetimeScope())
{
System.Threading.Thread.Sleep(5000); // Sleep simulates that it may take some time until other instances are resolved
using (businessLogic)
{
var task = businessLogic.Value.DoHardBusinessAsync();
task.Wait();
}
}
});
Look at this question for ideas on how to get a hold of the container
Retrieving Autofac container to resolve services

#NataliaMuray's approach is awesome - one downside of it is that it tends to encourage Service Locator style resolving rather than constructor injection. This can tend to "hide" dependencies, making it harder to identify the dependencies of a given class.
One potential solution is to introduce the notion of a dependency that is explicit that it wraps another dependency that you want to resolve outside the normal web request's lifetime scope.
The code might look something like:
public class AsyncRunner : IAsyncRunner
{
public ExecutionResult TryExecute<TService>(Action<TService> toEvaluate, string #exceptionErrorMessage, int timeoutMilliseconds, string additionalErrorInformation = "")
{
try
{
var task = new Task(() =>
{
using (var scope = container.BeginLifetimeScope())
{
var service = scope.Resolve<TService>();
toEvaluate(service);
}
});
task.ContinueWith(t => { /* logging here */, TaskContinuationOptions.OnlyOnFaulted | TaskContinuationOptions.ExecuteSynchronously).SuppressExceptions();
task.Start();
var completedWithinTime = task.Wait(timeoutMilliseconds);
return completedWithinTime ? ExecutionResult.Ok : ExecutionResult.TimedOut;
}
catch (Exception e)
{
/* logging here */
return ExecutionResult.ThrewException;
}
}
}
Register IAsyncRunner with Autofac as well.
And then your dependency, instead of
private readonly Func<Owned<IBusinessLogic>> _businessLogicFactory;
would be
private readonly IAsyncRunner<IBusinessLogic>> _businessLogic;
And instead of:
var businessLogic = _businessLogicFactory();
var unitOfWorkFactory = _unitOfWorkFactory;
Task.Run(() =>
{
System.Threading.Thread.Sleep(5000); // Sleep simulates that it may take some time until other instances are resolved
using (businessLogic)
{
var task = businessLogic.Value.DoHardBusinessAsync();
task.Wait();
}
});
would be:
//var businessLogic = _businessLogicFactory();
var unitOfWorkFactory = _unitOfWorkFactory;
Task.Run(() =>
{
System.Threading.Thread.Sleep(5000); // Sleep simulates that it may take some time until other instances are resolved
_businessLogic.TryExecute(z => {
var task = z.Value.DoHardBusinessAsync();
task.Wait();
});
});
The advantage of this style is that the property and constructor injection makes clear what the dependencies are, and how they are being used (i.e. the declaration makes clear that it will be resolved outside the context of the standard lifetime scope). Note you don't need to use Owned with my suggestion (disposal of the lifetime scope that is manually constructed will be sufficient). I have removed the use of Func, but you could use Func or Lazy if you really needed it alongside my suggestion.

Can I clone DbContext from existing one?

I'm working on .NET Core Web API and I have one endpoint where I want to run three operations in parallel. All three of them use the same database, so I need three copies of DbContext. I created a simple Factory class, which I later inject into my "Data" class.
Is it possible (if it's, is a good practice), to inject DbContext into my factory class (using built in .NET Core IoC) and when someone calls "CreateMyDbContext" method, just deep clone the one which was injected at the beginning?
EDIT:
Here is the example with the DbContext Pool:
public class FooData : IFooData
{
private readonly Func<DisposableScopedContextWrapper> _func;
public FooData(Func<DisposableScopedContextWrapper> func)
{
_func = func;
}
public async Task<List<Apple>> GetApples()
{
using (var wrapper = _func())
{
var apples = await wrapper.Context.Apples.FromSqlRaw("SELECT.... complicated query").ToListAsync();
return apples;
}
}
public async Task<List<Orange>> GetOranges()
{
using (var wrapper = _func())
{
var oranges = await wrapper.Context.Oranges.FromSqlRaw("SELECT.... complicated query").ToListAsync();
return oranges;
}
}
}
public class FooService
{
private readonly IFooData _fooData;
public FooData(IFooData fooData)
{
_fooData = fooData;
}
public async Task<List<Fruit>> GetFruits()
{
var appleTask = _fooData.GetApples();
var orangeTask = _fooData.GetOranges();
(var result1, var result2) = await (appleTask, orangeTask).WhenAll();
// ...
}
}

I definitely would not recommend any deepcloning for multiple reasons, one of them being that you will need to figure out a lot of EF internals to make it right, and internals can change (and you will need to spend some time on it).
Second option would be just creating your context manually, which I would recommend against also cause modern infrastructure uses DbContext pooling.
So what you can to register Func<DbContext> (or create your own factory) like this:
services.AddSingleton<Func<DbContext>>(provider => () =>
{
var scope = provider.CreateScope();
return scope.ServiceProvider.GetRequiredService<DbContext>();
});
the issue here is that scope here would not be disposed and you can't (if you have default scope for your DbContext) dispose the scope inside the Func cause your context will be disposed also. So you can try creating some disposable wrapper so you can manually dispose everything like this:
public class DisposableScopedContextWrapper : IDisposable
{
private readonly IServiceScope _scope;
public DbContext Context { get; }
public DisposableScopedContextWrapper(IServiceScope scope)
{
_scope = scope;
Context = _scope.ServiceProvider.GetService<DbContext>();
}
public void Dispose()
{
_scope.Dispose();
}
}
services.AddSingleton<Func<DisposableScopedContextWrapper>>(provider =>() =>
{
var scope = provider.CreateScope();
return new DisposableScopedContextWrapper(scope);
});
Inject in your classes Func<DisposableScopedContextWrapper> func and use it
using (var wrapper = func())
{
wrapper.Context...
}

Azure WebJobs - multiple background task in single WebJob and Ef error An attempt was made to use the context while it is being configured

I have multiple background Batch jobs to Run and I have been asked to have single webJob to run all task, which I need to schedule to run at different time.
I have used Timer feature from webJob.Extensions.
i.e in the Program.cs
var config = new JobHostConfiguration
{
JobActivator = new AutofacActivator(ContainerConfig<Functions>.GetContainer())
};
if (config.IsDevelopment)
{
config.UseDevelopmentSettings();
}
config.UseTimers();
var host = new JobHost(config);
host.RunAndBlock();
And the function will have multiple method and are triggered in interval of 30 min.
public void ProcessMethod1([TimerTrigger("0 0/30 * * * *")] TimerInfo timer)
{
//Logic
}
public void ProcessMethod2([TimerTrigger("0 0/30 * * * *")] TimerInfo timer)
{
//Logic
}
Issue: Since I am using Autofac DI. I am creating the instance for dbContext at the start of the Job
JobActivator = new AutofacActivator(ContainerConfig<Functions>.GetContainer())
While executing the webJob I am getting errors while executing DB select like "An attempt was made to use the context while it is being configured".
Since I gave scope as InstancePerLifetimeScope(). I want to know if the Two operation will get same instance?
Also for Logging I have similar issue, since it looks like only one instance is created for these two different Operation.
All I want is to have separate instance for both DBCOntext and Logger based on operation. Pls advise me how I can set DI for this scenario.
Update:
public class AutofacActivator: IJobActivator
{
private readonly Autofac.IContainer _container;
public AutofacActivator(Autofac.IContainer container)
{
_container = container;
}
public T CreateInstance<T>()
{
return _container.Resolve<T>();
}
}
internal class WebJobIocModule<T> : Autofac.Module
{
protected override void Load(ContainerBuilder builder)
{
if (builder == null)
throw new ArgumentNullException("WebJobBuilder");
//Cascade
builder.RegisterModule(new BusinessObjectIocModule());
// Register the functions class - WebJobs will discover our triggers this way
builder.RegisterType<T>();
}
}
public class BusinessObjectIocModule :Autofac.Module
{
protected override void Load(ContainerBuilder builder)
{
if(builder == null) throw new ArgumentNullException("BusinessObjectBuilder");
//Cascade
builder.RegisterModule(new DataAccessRepoIocModule());
builder.RegisterType<BusinessObjBpc>().AsImplementedInterfaces();
}
}
In DataAccessIOC:
string connectionString = ConfigurationManager.ConnectionStrings["DBConnectionAppKeyName"].ConnectionString;
optionsStagingBuilder.UseSqlServer(connectionString);
builder.RegisterType<DataAccessDbContext>()
.AsSelf()
.WithParameter("options", optionsStagingBuilder.Options)
.InstancePerLifetimeScope();

If you use a LifetimeScope for the DbContext you should make sure that you make a new scope in each execution of the processing methods, by using code like this:
public void ProcessMethod1([TimerTrigger("0 0/30 * * * *")] TimerInfo timer)
{
using (var scope = container.BeginLifetimeScope())
{
//Logic
}
}
It would work, but I think it may have side effects. Also, for other components it is more efficient not to instantiate them in each execution of the processing methods. Perhaps you would like to use a different scope.
Update - How to inject the container in the function constructor:
In your constructor you can use a parameter Func<IContainer> instead of a IContainer. It will work as a container factory.
When you build your container (at the beginning of the job, at the point where you build your container) you register the instance of your container factory:
Func<IContainer> containerFactory = () => yourContainer;
...
builder.RegisterInstance(containerFactory);
Then in your constructor you let Autofac inject the factory and you store the container in a property:
public SomeConstructor(Func<IContainer> containerFactory, ...<other injected params>)
{
...
this.container = containerFactory();
}

Overriding AutoFac scoping configuration when using factory

How to configure AutoFac so that I get a new instance of Context every time I hit the factory. The Content component is set to InstancePerLifetimeScope(), which is perfect for 99% of my usage, but now I need a little extra control over how the Context component is scoped.
class Program
{
static void Main(string[] args)
{
var builder = new ContainerBuilder();
builder.RegisterType<Box>();
builder.RegisterType<DbContext>().InstancePerLifetimeScope();
var container = builder.Build();
using (var scope = container.BeginLifetimeScope())
{
var x = scope.Resolve<Box>();
}
Console.ReadKey();
}
}
class Box
{
public Box(DbContext.Factory factory)
{
factory();
factory(); // Want this to generate a NEW instance
Console.WriteLine("Box: {0}", GetHashCode());
}
}
class DbContext
{
public delegate DbContext Factory();
public DbContext()
{
Console.WriteLine("Context: {0}", GetHashCode());
}
}
Obviously, this is a rather simplified snippet of code. The problem I am trying to solve is that I have a huge stream of data coming into a service and I am trying to batch-save to the database. So, if Box can create new UOWs on demand, and release them back for disposal in a timely fashion, then I get a nice clean solution.
Thanks!

You can use Func<Owned<>> which works like a small ILifetimeScope :
public Box(Func<Owned<DbContext>> factory)
{
using (Owned<DbContext> ownedDbContext = factory())
{
// instance1
}
using (Owned<DbContext> ownedDbContext = factory())
{
// instance2
}
}
You can find more details on the Autofac documentation : Owned Instances
Another solution is to inject ILifetimeScope and then create a sub lifetimescope :
public Box(ILifetimeScope scope)
{
using (ILifetimeScope subScope = scope.BeginLifetimeScope())
{
DbContext dbContext = subScope.Resolve<DbContext>();
}
}
or
public Box(ILifetimeScope scope)
{
ILifetimeScope subScope = scope.BeginLifetimeScope();
scope.Disposer.AddInstanceForDisposal(subScope);
DbContext dbContext = subScope.Resolve<DbContext>();
// no need to dispose subScope,
// subScope (and dbContext) will be disposed at the same time as scope
}