Memory Leak 8.2.2 when using Odata to communicate with Business Central

[MikkelGlerup]

Our project is using .NET8
Odata 8.2.2

When running our project, each time the code does retrieves or saves data in Business Central through Odata the memory usage goes up without ever coming down:

var newOrderQuery = new DataServiceCollection<MtSalesInvoice>(_mtApiContext.MtSalesInvoices.Where(s => s.Id == new Guid("11111111-1111-1111-1111-111111111111")));
 var newOrder = new MtSalesInvoice();
 newOrderQuery.Add(newOrder);
 newOrder.CustomerNumber = existingCustomer.Number;
 newOrder.InvoiceDate = DateTime.Now.Date;
 newOrder.UniqueReference = locator;
 newOrder.IsMarkedForInvoiceCheck = operation.Order.IsMarkedForInvoiceCheck;
 _mtApiContext.SaveChanges(SaveChangesOptions.PostOnlySetProperties);

 _mtApiContext.Detach(newOrderQuery);

looking at memory heap most of it not all memory is being taken by Odata.

[mikepizzo]

Did you notice this as a regression from a previous version, or do you know if the same issue occurs in earlier versions?

[corranrogue9]

@MikkelGlerup the most common reason for memory issues in the OData client is having entity tracking enabled. This issue is exacerbated if you are also creating a new instance of your data service context (_mtApiContext in your case) instance for each client request. If you disable entity tracking on the machine that is executing the client, does that resolve your memory issue?

[MikkelGlerup]

Did you notice this as a regression from a previous version, or do you know if the same issue occurs in earlier versions?

We had the same problem running 7.2, however I didn't look more into how much, since I read that 8.0 had memory optimization and decided to update

[MikkelGlerup]

@MikkelGlerup the most common reason for memory issues in the OData client is having entity tracking enabled. This issue is exacerbated if you are also creating a new instance of your data service context (_mtApiContext in your case) instance for each client request. If you disable entity tracking on the machine that is executing the client, does that resolve your memory issue?

how do I disable entity tracking in this case?

unfortunately we don't create new instances of our data service contexts. This was my first thought, and to be sure I double checked just now.

[habbes]

@MikkelGlerup If you're using a single instance of the DataServiceContext throughout your app, and your process is long-running, and client-tracking is enabled, then it's possible that the DataServiceContext's entity tracker can grow in size over time (e.g. each time it fetches entities from the server, if those entities will be stored and cached on the client side in the local entity tracker if they don't already exist in the tracker). It's hard to tell whether that's what your service is facing without having additional information such as screenshot of the memory profiler's snapshot of objects in memory, or a repro project that demonstrates the issue. It would also be good to force garbage collection and see if memory use goes down, or if it says up even after full GC.

That said, you could disable entity tracking and see if that helps:

new MyDataServiceContextClass
{
   MergeOption = MergeOption.NoTracking
}

PS: If this fixes the problem we should have an article about this in our performance guidelines docs: MicrosoftDocs/OData-docs#317

[MikkelGlerup]

@habbes
Even if we detach the object every time like so:

This finally is run at the end of every operation.

I'd love to use

new MyDataServiceContextClass
{
   MergeOption = MergeOption.NoTracking
}

However with the way Business Central uses Odata it is impossible. You'd get errors telling you how the object you're saving has already changed if it is not tracked.

Memory heap:

It would also be good to force garbage collection and see if memory use goes down, or if it says up even after full GC.

I've already tried testing this through the code snippet I screenshot first, and nothing changed, well except the memory which rose 😄