These are chat archives for petabridge/akka-bootcamp

9th
Jun 2015
Ivan R. Perez
@irperez
Jun 09 2015 01:00
Guys at petabridge, setting up the logger configuration wasn't obvious. While I followed the documentation online, it wasn't clear per log component what the class name, assembly should be. It would be nice to see that clearly per logger component. In particular I'm talking about how to setup the HOCON. Just my 2 cents...
Mike Clark
@mclark1129
Jun 09 2015 02:35
Hey guys, just wanted to say that I have loved the lessons so far. The hands on experience has made it really easy to see how I could use Akka.NET to refactor some existing systems I work with. I'm through Unit 2 now, and I'm starting to wonder what the value of an UntypedActor is? Seems like the ReceiveActor provides a much more elegant way to handle messages other than a switch statement.
Bartosz Sypytkowski
@Horusiath
Jun 09 2015 08:22
@mclark1129 Untyped actors are good base classes for custom common actors in case when you don't want to return handling flags. It's easier to reason about Become/Unbecome and finite state machines when using UntypedActors rather than ReceiveActors. Also it's better for micro optimizations if needed.
Andrey Leskov
@andreyleskov
Jun 09 2015 10:33
@Aaronontheweb thanks for detailed explanation!
Aaron Stannard
@Aaronontheweb
Jun 09 2015 17:20
@irperez yeah, that's an area where we know we need to improve our docs
we're going to work on some of that as part of the official http://getakka.net/ docs
Ivan R. Perez
@irperez
Jun 09 2015 18:53
@Aaronontheweb I'll try to help when I get a chance.
Maciek Misztal
@mmisztal1980
Jun 09 2015 19:59
I'm going through lesson 3.1, while the router theory explanation is fantastic, the excercise deals with an un-touched topic of 'stashing' - this is somewhat inconsistent, as I had small problems understanding what am I doing here. The getakka.net documentation is ok, but some things are still unclear to me (possibly due to the fact that english is my secondary language). For instance - how the heck is stashing the same message multiple times is illegal? If I stash, then unstash - can't I stash the message again?
What I meant to say is - could you guys add some additional info on stashing to 3.1? For consistency's sake? Phas2 of the excercise doesn't exactly explain what's happening there
Ivan R. Perez
@irperez
Jun 09 2015 20:04
@mmisztal1980 I believe if you've already unstashed your messages you can stash them again. But you can't stash the same message twice while its in the stash.
Maciek Misztal
@mmisztal1980
Jun 09 2015 20:26
@irperez yeah, that is my guess as well
Betwulf
@Betwulf
Jun 09 2015 20:30
Hi guys! First, thanks for putting together the bootcamp - it is a great way to get a deep understanding of the framework.... I just finished 2.4 - Behaviors, and was wondering what would happen if an actor crashed and restarted - would akka.net remember what behavior the actor had "become"? Does it save the "stack"?
Bartosz Sypytkowski
@Horusiath
Jun 09 2015 20:31
@Betwulf no, it won't. Just like it won't save a state unless you decide to use persistent actors
@mmisztal1980 stashing is mostly for scenarios when you got messages incoming in random order in different points in time, but some of them must be processed before the others
Betwulf
@Betwulf
Jun 09 2015 20:36
@Horusiath - Thanks for the quick answer!
Andrew Skotzko
@skotzko
Jun 09 2015 20:44
@mmisztal1980 Stashing is covered in detail in the last lesson of Unit 2, right before 3.1 >> https://github.com/petabridge/akka-bootcamp/tree/master/src/Unit-2/lesson5
Maciek Misztal
@mmisztal1980
Jun 09 2015 20:49
@skotzko crap - need to read it again :D
Maciek Misztal
@mmisztal1980
Jun 09 2015 21:09
@skotzko correct me if I'm wrong - unstashing a single message has a LIFO result?
Andrew Skotzko
@skotzko
Jun 09 2015 21:10
correct
unstashing one message at a time can change the initial message order and make it LIFO
Stash.UnstashAll() will preserve FIFO order and put whole stash back in mailbox
in original order
(it can be a little confusing)
Ivan R. Perez
@irperez
Jun 09 2015 21:51
@Horusiath but not always used for processing in order. you can also use Stash to apply a CircuitBreaker design such as if a remote resource goes down. You can stash messages until the resource comes back up again. See this article (https://stackoverflow.com/questions/28387589/how-to-handle-exceptions-within-the-actor-in-akka-net#). I could be wrong, but I'm looking at this as a way to queue up messages for processing once the remote resource is available again.
Bartosz Sypytkowski
@Horusiath
Jun 09 2015 22:32
@irperez yes, it could be used in multiple scenarios, I've said about one of them. The problem I see with your example is that, time necessary for external service to restart is potentially undeterministic. If it will take longer time to be responsive again, you may 1) got so many messages that you'll consume all the memory for stashing 2) according to reactive manifesto principles, from the user perspective there is basically no difference between service which responds with great delay (tens of seconds) and the one that is actually unresponsive. In that case stash should have bounded limit and another type of failure notificaton or backpressure mechanism should be attached.