Closed johnkattenhorn closed 5 years ago
So we've confirmed today that the OnDeactivate method is being called on the Actor and that Actor no longer appears in the memorydump but I can't think of a way to remove the child logger from the memory.
@alexmg, @nblumhardt - would simply setting the ILogger
to null work ? How about casting the return ILogger
to Logger
so I can run the Dispose
method on it?
Maybe I'm getting hung up in the memory dump; if it's not in Gen2 it should be ok right unless (%) Timespent in GC
gets too high.
ForContext returns an ILogger which does'nt implement IDisposable that this logger does not have cleanup up even after the Actor is deactivated.
The loggers returned by ForContext
don't implement IDisposable
because they don't need any clean-up. If they're hanging around, it'll be because some other retained object is referencing them (or just that GC hasn't run on a high enough generation, yet).
HTH!
Hopefully this has helped; if not, StackOverflow might get you an answer sooner.
I've been asked to come out of coding retirement to look at a production issue :-)
It seems we have a problem with disposing of Serilog objects judging by a memory dump.
In
program.cs
with register a module with this codeWe then register the Actor like this:
The Actor Class looks like this:
Where DeviceActor is a abstract class inheriting from
Microsoft.ServiceFabric.Actors.Runtime.Actor
, maybe significantly neither the abstract class or the concrete class implement IDisposable.My worry is that when the given
ForContext
returns anILogger
which does'nt implementIDisposable
that this logger does not have cleanup up even after the Actor is deactivated.Does anyone have a view about this approach or see what might be causing us to hold onto the Serilog objects ?
Should I make the Actor IDisposable or implement some kind of
OnRelease
in the Actor registration ?