These are chat archives for petabridge/akka-bootcamp

9th
Jul 2015
Thomas Lazar
@thomaslazar
Jul 09 2015 06:33
@Aaronontheweb did you see the discussion about canceling a working actor/killing child actors from yesterday? any comments on that? especially on how akka handles stuff like the killing child actors off if one of them fails.
could you give a comment about that stuff?
Aaron Stannard
@Aaronontheweb
Jul 09 2015 06:33
I saw the discussion
but wasn't sure if there was anything left unresolved there, so thanks for letting me know that there is!
So here's a high level thought for you
and anyone else who's interested
Thomas Lazar
@thomaslazar
Jul 09 2015 06:34
well mostly how akka handles the killing off of child actors. do they die immediately or do they run to conclusion. and how do you handle actors that are in an infinite loop and can't ever complete
Aaron Stannard
@Aaronontheweb
Jul 09 2015 06:35
ah, well that's a great question
so because we like to confuse people in Akka.NET
we have three different ways of killing off actors
Thomas Lazar
@thomaslazar
Jul 09 2015 06:35
i know that :P
Aaron Stannard
@Aaronontheweb
Jul 09 2015 06:35
PoisonPill
Kill
and Context.Stop
Context.Stop is designed specifically for parents to kill children
at the parent level, it immediately marks the child as slated for termination
and will send the child a Terminate command, which is a system level message
that means the child dies once it's immediately finished processing its current message
it also changes some of the state inside the parent's ChildContainer to mark that child as terminating before the child ever receives the message
so it's probably the best tool for the job for that
PoisonPill is a user-level message
the actor shuts down AFTER it finishes processing the rest of the messages in its mailbox
Thomas Lazar
@thomaslazar
Jul 09 2015 06:39
the rest?
messaged that come in after are ignored, are they?
Aaron Stannard
@Aaronontheweb
Jul 09 2015 06:39
Kill does the same thing as PoisonPill, but the actor throws an ActorKilledException afterwards
@thomaslazar yeah, the rest of the messages queued up behind the PoisonPill go to dead letters
Thomas Lazar
@thomaslazar
Jul 09 2015 06:40
ok
so good so far
how about killing off an actor that`s gone rogue?
Aaron Stannard
@Aaronontheweb
Jul 09 2015 06:40
so the answer to this question > do they die immediately or do they run to conclusion
lies in how you stop the actor
as for actors who are live-locking
or stuck in some sort of infinite loop
that's a trickier problem, especially if it's generating messages that don't get GCed in gen 0
(hint: because those message objects go from the actor to a mailbox, they definitely don't get GCed in gen 0)
eventually an OutOfMemoryException will solve that problem for you :p
there's different ways an actor can get "stuck"
Thomas Lazar
@thomaslazar
Jul 09 2015 06:42
well i don`t know if i want to wait that long :P
Aaron Stannard
@Aaronontheweb
Jul 09 2015 06:42
the most likely culprits are sending messages to self
in a loop
and having some piece of work that the actor processes lock the OnReceive method
we don't support anything right now for "aborting" an actor like you would a thread
the way I would solve the latter is take any long-running task and have the actor execute it inside a task with a CancellationToken
so the actor can continue to respond to messages even if it's "busy"
the dedicated threadpool has built-in deadlock detection
which can be invoked on actors who are configured to use the PinnedDispatcher or the ForkJoinDispatcher
but the results from that might be unpredictable
Thomas Lazar
@thomaslazar
Jul 09 2015 06:47
ok. so best solution is mainly to just design your stuff so you don`t have very long blocking tasks
Aaron Stannard
@Aaronontheweb
Jul 09 2015 06:47
now that I think about it, the right way to handle a deadlock inside an actor would be to crash it
yeah, ideally
break up long-running tasks into series of messages that can be executed asynchronously
you can still have asynchronous execution of a serial process
Thomas Lazar
@thomaslazar
Jul 09 2015 06:48
and if not "outsource" the work into a task and have it react to a cancel signal
Aaron Stannard
@Aaronontheweb
Jul 09 2015 06:48
yes
if you do either of those then you can still use the actor the control the flow
Thomas Lazar
@thomaslazar
Jul 09 2015 06:50
good. thanks for clearing up the three ways to kill actors (<- some of these sentences really don't sound nice out of context)
would be cool if there could be some addendum to the bootcamp that makes that one a bit clearer
Aaron Stannard
@Aaronontheweb
Jul 09 2015 06:50
yeah, I've been asked that question a few times lately
I'll put up a blog post about it
@njimenez btw, saw your post - I'll check out the README tomorrow and let you know!
Arjen Smits
@Danthar
Jul 09 2015 07:17

yeah, I've been asked that question a few times lately

@Aaronontheweb Seeing this, makes me wonder if the docs needs some kind of improvement, perhaps some more clarification around this topic. Or just have this topic be better visible in the ToC of the website. http://getakka.net/docs/Working%20with%20actors#stopping-actors

Aaron Stannard
@Aaronontheweb
Jul 09 2015 07:17
all of the docs need some major love
yeah, I'd break that stuff out into their own links in the TOC
or separate pages
Arjen Smits
@Danthar
Jul 09 2015 07:18
All the stuff in Working with actors?
Aaron Stannard
@Aaronontheweb
Jul 09 2015 07:19
there's chunks in there, like stopping actors
Arjen Smits
@Danthar
Jul 09 2015 07:19
Im aware of: akkadotnet/getakka.net#7 but im unsure of the state, of who's working on what
Aaron Stannard
@Aaronontheweb
Jul 09 2015 07:19
that merit their own top-level link
Arjen Smits
@Danthar
Jul 09 2015 07:20
agreed
Stopping Actors and Killing actors should be under one topic.
Aaron Stannard
@Aaronontheweb
Jul 09 2015 07:27
@Danthar it's in a bit of free for all at the moment
Arjen Smits
@Danthar
Jul 09 2015 07:28
I have some time free I can spend on this at the end of the day. I could do some restructuring on the Working with Actors page.
lets take this discussion to the akka.net chat