These are chat archives for akkadotnet/akka.net

24th
Aug 2018
grantelgin
@grantelgin
Aug 24 2018 15:14
@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
Aug 24 2018 16:47
@grantelgin happy to help
the dark art of memory profiling strikes again
Lealand Vettleson
@spankr
Aug 24 2018 19:56
@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
Aug 24 2018 20:36
are there any best practices for dealing with exceptions with PipeTo ?
Aaron Stannard
@Aaronontheweb
Aug 24 2018 20:36
@Lutando I write a continuation handler
before the exception ever gets to PipeTo
PipeTo is just a delivery mechanism
Lutando Ngqakaza
@Lutando
Aug 24 2018 20:37
i guess this isnt akka specific, more like, thread exception handling
ah ok
Aaron Stannard
@Aaronontheweb
Aug 24 2018 20:37
exception handling should occur after the original Task
Lutando Ngqakaza
@Lutando
Aug 24 2018 20:37
awesome
Aaron Stannard
@Aaronontheweb
Aug 24 2018 20:37
just like most other TPL programming
my $0.02
Lutando Ngqakaza
@Lutando
Aug 24 2018 20:38
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
Aug 24 2018 20:40
let me see if I can dig up an example real fast
handling HTTP response codes
in that sample
Lutando Ngqakaza
@Lutando
Aug 24 2018 20:42
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
Aug 24 2018 20:43
I need to get rid of those TBH
it's something I used to do more often
Lutando Ngqakaza
@Lutando
Aug 24 2018 20:44
get rid of all of them?
Aaron Stannard
@Aaronontheweb
Aug 24 2018 20:44
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
Aug 24 2018 20:44
so there would be "one" way to do it?
Aaron Stannard
@Aaronontheweb
Aug 24 2018 20:44
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
Lutando Ngqakaza
@Lutando
Aug 24 2018 20:45
ahh
Aaron Stannard
@Aaronontheweb
Aug 24 2018 20:45
so I probably wouldn't specify any of those TaskContinuationOptions any longer
just because it's not necessary, makes the code less easy to understand, could have unintended consequences, and the TaskScheduler may not even be able to execute them in some cases
i was really under the impression async await would be ok for most of my cases by the perf hit is quite hard for me to actually reason about
Aaron Stannard
@Aaronontheweb
Aug 24 2018 20:47
async await inside an actor
is serial
Lutando Ngqakaza
@Lutando
Aug 24 2018 20:47
yeah
Aaron Stannard
@Aaronontheweb
Aug 24 2018 20:47
actor can only process one await-able operation at a time
PipeTo is concurrent
can have several of those running simultaneously
Lutando Ngqakaza
@Lutando
Aug 24 2018 20:49
right now im of the opinion that singleton actors with state doing lots of async await should probably pipeto, and stateless actors doing rudimentary async operations can get away with async await
because you can just spawn more of those stateless kinds to do work, its lazy but it works
Aaron Stannard
@Aaronontheweb
Aug 24 2018 20:49
the way I look at it is
is it desirable to block the actor's message processing flow while this async operation executes?
i.e. you will want to block an "AuthenticationActor" from processing any other requests until the user's authentication attempt succeeds or fails
in that case, I'll just use await - easier to do that than to use behavior-switching
(in that case, at least)
if it's not desirable to block the actor's message processing while the async operation runs
use PipeTo
Lutando Ngqakaza
@Lutando
Aug 24 2018 20:51
ah fair enough
thats actually better than mine it encompasses more scenarios
Aaron Stannard
@Aaronontheweb
Aug 24 2018 20:51
and in general, you should shoot for trying to make async workflows non-blocking when you get the chance
allows for some of the higher level patterns that the TPL makes possible
task composition and so forth
but there are some situations where blocking the logical flow of execution is the right call
authentication being one relatable example that every developer is familiar with
really anything with a "transactional" nature to it probably falls in that category
like if you're processing multiple transactions against the same bank account
you want to make sure those transactions start and complete in the order in which they were received
therefore, blocking the flow of execution is a really understandable way of modeling that
transaction B to account X can't start until transaction A to account X completes
but if you're doing something that is decidedly not transactional
i.e. building a real-time analytics service
where you have a ton of clickstream events coming in
that system would implode rather quickly if you blocked the flow of execution
so that's how I orient my thinking around it - the other case where I'd be tempted to use await in my own actors is when the error-handling is really complex
it's easier to do that type of work using a simple try...catch block with an await call somewhere inside the try than it is to write a continuation function for that
Aaron Stannard
@Aaronontheweb
Aug 24 2018 20:57
most error-handling I do around a Task is usually pretty simple though
like that sample I linked
Lutando Ngqakaza
@Lutando
Aug 24 2018 21:02
hmm ok, but simple "validated" DoThisThingNoMatterWhatCommand type of things are best for pipeto since they are in the category of things that must be done anyways, and unlike the scenario you outlined above it doesnt call for transactional ordering
Aaron Stannard
@Aaronontheweb
Aug 24 2018 21:02
yeah, exactly
if you're just firing off HTTP requests to some Web API
and the ordering doesn't matter
i.e. you can have all of those operations running concurrently
PipeTo is your friend
and you can just have a continuation Task do the "DoThisThingToTheResponseFromTask" before the PipeTo
John Haigh
@haighis
Aug 24 2018 23:27

Hello. I'm trying to brainstorm the best way to create a sequential process of steps in akka .net I.e.
Step 1 - insert some data into a database
Step 2 - call an external web service after step 1 completed
Step 3 - send an email after step 2 completes.

This is sometimes referred to as a Batch Processor or Job Manager