Memory Leak due to Telemetry

Category

• Bug

Describe the bug

One of my teammates has been hunting a memory leak in our software for a few weeks now. Last night was the first night we saw zero increase in memory usage and it’s because we set the PnPCoreOptions.DisableTelemetry to false.

He had narrowed it down to Application Insights, and after finally getting a good profile from ANTS, saw that it all revolved around TelemetryManager and the TelemetryConfiguration in there.

I noticed in PnPContext.Dispose the comment:

// Note: flushing telemetry does not belong here since apps potentially can create/dispose a lot of contexts

And I get it. Since we’re sharing the TelemetryManager amongst the PnPContexts and PnPContextFactory, it’s not like any of those can dispose it without hurting others.

One suggestion my teammate had was to allow us to pass in a static TelemetryConfiguration so that it’s not instantiated every time.

Use Case

I realize we use PnP.Core a little different than most. We use it VERY dynamically and do not pre-register sites. We are a multi-tenant SaaS product, and we take it one step further: every long-running job (a la SharePoint Timer Job) is wrapped in its own Autofac.ILifetimeScope where we inject the current tenant. When the job is done, we dispose the scope and ideally, everything with it.

While I’m sure that the DI frameworks and GC should do most of the work, we have found that to not always be the case, so we try to be meticulous in our IDisposables.

Since PnPCoreContextFactory is registered as a transient, sure seems like we’re instantiating a LOT of TelemetryConfigurations, when we probably shouldn’t.

[jansenbe]

Thanks for raising this @DaleyKD , if this results in unneeded memory pressure then let’s see how it can be done different.

[jansenbe]

@DaleyKD : Based upon my research it should, please let me know if you encounter issues