Question regarding how to correctly implement Akka.Persistence.Journal.AsyncWriteJournal.WriteMessagesAsync. Since each AtomicWrite corresponds to either a call to Akka.Persistence.Eventsourced.Persist or Akka.Persistence.Eventsourced.PersistAll, is it guaranteed that each call to Akka.Persistence.Journal.AsyncWriteJournal.WriteMessagesAsync always will pass an IEnumerable of atomic writes with unique persistent ids?
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.
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