Has anyone seen issues with the Task -> ContinueWith -> PipeTo pattern preventing the Garbage collector from cleaning up? I'm using akka.net to update a legacy app that has many long running tasks that consume gigs of ram. The performance improvements are spectacular so far, but I've got a memory leak I assume is occurring because the PipeTo Extension maintains a reference to the task or to the task return object. My current solution is to force a GC Collect when ram gets close to max. I assume there must be a better solution I'm not aware of? Thanks for any help.
@grantelgin so my go-to for troubleshooting memory leaks
I run it with "snapshot when memory increases by more than %" mode
and let the thing run long enough to gather 3-4 snapshots
and then I use DotMemory's comparison tool to see which roots are responsible for the increases in memory over time
recently debugged an issue where AutoMapper was doing something crazy and allocating a bunch of rooted anonymous methods that never got GCed
it's possible that Task can close over things and not let it get GCed, depending on how the code is written
but before you go trying to rewrite some of that code, I'd recommend you get some data with the memory snapshots collected from DotMemory
and if you need help analyzing them, feel free to send me a copy of your dotmemory workspace with all of the snapshots - those files can get a little big so you may want to stick it in OneDrive or something and DM me a link
RIght on. Thanks Aaron. I'll re-enable Resharper Ultimate and give that a try
the stand alone DotMemory desktop app
is the right tool for the job there
after you've compiled the exe
that's what will get you the snapshots over time et al
I think it works by just grabbing the ETW counters emitted by the process it launches or attaches to
@Aaronontheweb Thanks for the help yesterday. The memory issue happened because I assigned the Task to a class member variable. Once I removed the variable assignment, the GC did its job.
@grantelgin happy to help
the dark art of memory profiling strikes again
@featuresnap Sorry about the late response on this one (big push to production here this spring/summer). Our solution to this was to proxy/route the messages, it that makes sense. TestActors and probes still live under /system but the actors under test don't know the difference. Its been a while since you posted so I'm assuming you have this resolved. If not, just ping me and I'll see if I can find an example test that hopefully explains what we did.
are there any best practices for dealing with exceptions with PipeTo ?
@Lutando I write a continuation handler
before the exception ever gets to PipeTo
PipeTo is just a delivery mechanism
i guess this isnt akka specific, more like, thread exception handling
exception handling should occur after the original Task
just like most other TPL programming
so you mean inside the continuation lamdba do a try catch?
and then do some control flow on the exception inside of that?