These are chat archives for petabridge/akka-bootcamp

8th
Jul 2015
Igor Ziselman
@constructor-igor
Jul 08 2015 05:56
@Aaronontheweb yes.
Thomas Tomanek
@thomastomanek
Jul 08 2015 10:03
@constructor-igor couldn't you just make your long running business task asynchronous so you don't stop your actor receiving any new messages and then pipe the result of the task back to yourself when it's done? Then your actor would be free to receive cancellation messages from other actors
Igor Ziselman
@constructor-igor
Jul 08 2015 11:05
@sadprofessor it means, I start to implement "async" code inside actor. As I understand, actor model allows us to avoid implement async code inside each actor.
Bartosz Sypytkowski
@Horusiath
Jul 08 2015 11:12
@constructor-igor actor model is about concurrency, not asynchrony. But the question is: how would you achieve your goal in non-asynchronous code?
Igor Ziselman
@constructor-igor
Jul 08 2015 11:17
@Horusiath yes
Bartosz Sypytkowski
@Horusiath
Jul 08 2015 11:20
@sadprofessor 's idea may be just sufficient and quite easy to implement. If you'd like to implement cancellable on the code, which is inherently synchronous (and that is the single actor behavior by default), you'd probably need to split your work into some steps and at the beginning of each step make a check for possible cancellation request.
I don't know if it's worth the effort
Bartosz Sypytkowski
@Horusiath
Jul 08 2015 11:26
eventually you could pass AtomicBoolean in actor message, check it inside an actor and switch it outside actor's context. This would work but also violates one of akka principles (immutable messages) and may introduce smell to your code. But you know: working code > pretty code ;)
Igor Ziselman
@constructor-igor
Jul 08 2015 11:31
@Horusiath yes, as workaround I can place to message CancellationToken and work with them, but what about "akka principles (immutable messages) " ? I don't want lost the principle.
Bartosz Sypytkowski
@Horusiath
Jul 08 2015 11:35
go for @sadprofessor 's advice ;) it's easy (as long as you don't mess with Context) and can be used with remote actors
Thomas Lazar
@thomaslazar
Jul 08 2015 11:59
would not a solution be to just implement a manager actor that stands above the blocking one that has a state "can work" and one "working" and accepts a cancel message in "working" and just kills the child actor when he gets a cancel message? something like that?
don`t really know how immediate killing child actors is
Arjen Smits
@Danthar
Jul 08 2015 12:00
afaik there is no way to forcibly kill an actor
Thomas Lazar
@thomaslazar
Jul 08 2015 12:01
so it is always a wait till child is done and then kill it
Arjen Smits
@Danthar
Jul 08 2015 12:01
which is what you would want to do if your actor is stuck in a busy loop. Since it wont be able to process messages, and thus the kill message will never be processed.
Thomas Lazar
@thomaslazar
Jul 08 2015 12:02
well maybe some of the higher ups can answer that. :)
Arjen Smits
@Danthar
Jul 08 2015 12:02
killing an actor is async, you can be notified of the event that your actor is stopped by listening to the Terminated message in combination with Context.Watch
Thomas Lazar
@thomaslazar
Jul 08 2015 12:02
yeah but if the blocking actor runs 10 minutes then he`s still running his full 10 minutes.
Arjen Smits
@Danthar
Jul 08 2015 12:02
yup
Roger Johansson
@rogeralsing
Jul 08 2015 12:03
the dedicated threadpool can actually do this. it has a setting to kill non responsive threads after x time
Thomas Lazar
@thomaslazar
Jul 08 2015 12:03
how is the system doing the "kill everything if one child dies" supervision strategy though? wouldn't you just want the stuff to stop immediately?
Roger Johansson
@rogeralsing
Jul 08 2015 12:04
it doesnt, the one for all strategy is also async, and there is no guarantee that all children restart at the exact same time
Thomas Lazar
@thomaslazar
Jul 08 2015 12:04
ok. good to know
Roger Johansson
@rogeralsing
Jul 08 2015 12:05
(which I agree with is strange, but its the JVM behavior too)
Bartosz Sypytkowski
@Horusiath
Jul 08 2015 12:05
@rogeralsing I've seen that Stop/Terminate messages are handled in special way
Arjen Smits
@Danthar
Jul 08 2015 12:05
@rogeralsing regarding the dedicated threadpool thats good to know. Its off by default right ?
Thomas Lazar
@thomaslazar
Jul 08 2015 12:05
so the main thing in that case would be "don't write actors with long blocking code that you want to kill"
Arjen Smits
@Danthar
Jul 08 2015 12:06
@rogeralsing thats good to know. Its off by default right ?
@thomaslazar that would be my approach
Roger Johansson
@rogeralsing
Jul 08 2015 12:06
@Danthar yes
Nelson Jimenez
@njimenez
Jul 08 2015 17:35
@Aaronontheweb I checked in a readme.md to the https://github.com/njimenez/AkkaProjects take a look at it and let me know what you think.
AaronLenoir
@AaronLenoir
Jul 08 2015 22:49
What would be the preferred choice to send a message to multiple Actors, using pub-sub or using an ActorSelector with some kind of wildcard. What does the choice depend on? Pub-sub seems better since the Actor itself is then not concerned with finding those Actors that must be notified, since they tell the Actor they want to receive the messages. On the other hand, selectors allow you to send stuff to an Actor that may or may not exist, which also seems useful. Any "rule of thumb" to see what fits best in a certain case?
Aaron Stannard
@Aaronontheweb
Jul 08 2015 22:50
pub-sub and explicit communication will get you the best results
IMHO
wildcard actor selections is a shotgun based approach
and if your actor hierarchy design changes over time, those can bite you in the ass
on top of that, pub-sub is reactive - plays very nicely with actors
I'd only use wildcard actor selections in cases where you really need to broadcast a message to an unknown number of actors at a certain position in the hierarchy