Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 16:03
    Aaronontheweb commented #3851
  • 11:40
    Aaronontheweb synchronize #3914
  • 08:46
    BartHuls closed #3895
  • 00:33
    Aaronontheweb commented #3851
  • 00:32
    Aaronontheweb synchronize #3914
  • 00:23
    Aaronontheweb milestoned #3851
  • Sep 19 23:23
    Aaronontheweb commented #3851
  • Sep 19 23:19
    Aaronontheweb edited #3914
  • Sep 19 23:12
    Aaronontheweb commented #3914
  • Sep 19 22:53
    Aaronontheweb synchronize #3914
  • Sep 19 22:23
    Aaronontheweb milestoned #3920
  • Sep 19 22:23
    Aaronontheweb opened #3920
  • Sep 19 22:23
    Aaronontheweb labeled #3920
  • Sep 19 22:14
    Aaronontheweb synchronize #3914
  • Sep 19 22:11
    Aaronontheweb synchronize #3914
  • Sep 19 22:08
    Aaronontheweb synchronize #3914
  • Sep 19 22:05
    Aaronontheweb synchronize #3914
  • Sep 19 21:01
    Aaronontheweb synchronize #3914
  • Sep 19 20:23
    Aaronontheweb synchronize #3914
  • Sep 19 20:11
    Aaronontheweb synchronize #3914
grantelgin
@grantelgin
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.
Aaron Stannard
@Aaronontheweb
@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
grantelgin
@grantelgin
RIght on. Thanks Aaron. I'll re-enable Resharper Ultimate and give that a try
Aaron Stannard
@Aaronontheweb
the stand alone DotMemory desktop app
is the right tool for the job there
IMHO
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
grantelgin
@grantelgin
Great Thanks.
Aaron Stannard
@Aaronontheweb
Akka.Logger.Serilog is now upgraded for v1.3.9 as well: https://github.com/akkadotnet/Akka.Logger.Serilog/releases/tag/v1.3.9
fixes a regression I introduced in v1.3.6 :(
grantelgin
@grantelgin
@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.
Aaron Stannard
@Aaronontheweb
@grantelgin happy to help
the dark art of memory profiling strikes again
Lealand Vettleson
@spankr
@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.
Lutando Ngqakaza
@Lutando
are there any best practices for dealing with exceptions with PipeTo ?
Aaron Stannard
@Aaronontheweb
@Lutando I write a continuation handler
before the exception ever gets to PipeTo
PipeTo is just a delivery mechanism
Lutando Ngqakaza
@Lutando
i guess this isnt akka specific, more like, thread exception handling
ah ok
Aaron Stannard
@Aaronontheweb
exception handling should occur after the original Task
Lutando Ngqakaza
@Lutando
awesome
Aaron Stannard
@Aaronontheweb
just like most other TPL programming
my $0.02
Lutando Ngqakaza
@Lutando
so you mean inside the continuation lamdba do a try catch?
and then do some control flow on the exception inside of that?
Aaron Stannard
@Aaronontheweb
let me see if I can dig up an example real fast
handling HTTP response codes
in that sample
Lutando Ngqakaza
@Lutando
awesome
im still not too clear on those task continuation options although TaskContinuationOptions.ExecuteSynchronouslyfeels like the most conventional one for my mental model right now
Aaron Stannard
@Aaronontheweb
I need to get rid of those TBH
it's something I used to do more often
Lutando Ngqakaza
@Lutando
get rid of all of them?
Aaron Stannard
@Aaronontheweb
ExecuteSynchronously is harmless when all you're doing is perfoming a quick mapping between an output type and a DTO or something
Lutando Ngqakaza
@Lutando
so there would be "one" way to do it?
Aaron Stannard
@Aaronontheweb
but truth is these are things you can use to shoot yourself in the foot if you're not careful
so I feel more comfortable just letting the TaskScheduler decide what to do
it's an opinion of mine that has evolved over the years