These are chat archives for akkadotnet/akka.net

15th
Jun 2015
Björn Holdt
@bholdt
Jun 15 2015 00:25
hey all. When a child actor crashes, I am expecting that a Failure message gets sent to the parent. However, the parent never seems to be notified of a failure message
On the child actor I can check if an exception occurred as follows:
protected override void PreRestart(Exception reason, object message)
But I was expecting that a message of type Failure would also be sent to the parent
"The system sends a Failure message from c1 to p1, with the Exception that was raised."
Any ideas?
Roger Johansson
@rogeralsing
Jun 15 2015 01:31
It is but its not observable from your receive methods
It gets sent to the parents supervisor strategy only
Björn Holdt
@bholdt
Jun 15 2015 01:40
Ah right. That makes sense. Thanks
Should the parent not receive a Terminated message?
Björn Holdt
@bholdt
Jun 15 2015 01:45
Or does that happen only if the directive was to stop the actor?
Roger Johansson
@rogeralsing
Jun 15 2015 01:50
Exactly, terminated is when the child permanently dies, not when restarted
Roger Johansson
@rogeralsing
Jun 15 2015 11:18
gah git.. how do I fetch an upstream branch to local so I can push it to my origin
?
James Forrest
@Gumpy
Jun 15 2015 14:34
Would it possible to do live code updates to an actor without a system restart? Say you find a bug in an actors implementation, could you "redeploy" the actor without missing any messages in a running system?
Anthony Brown
@bruinbrown
Jun 15 2015 15:36
@Gumpy there's a couple of ways to do it, it's really easy with the F# API, you just create a message with the new message handler as a function and send that, then just call it and work like that, I think Riccardo Terrell did an example of that somewhere
@Gumpy the second approach is to use Akka.Persistence and Akka.Cluster, each actor uses the at least once message delivery actor from Persistence and is deployed into a cluster. To upgrade, bring down half of the cluster and actors on that machine get redeployed to one which is still up. When everything is balanced, bring down the remaining original half and upgrade that
James Forrest
@Gumpy
Jun 15 2015 15:48
@bruinbrown Thankyou very much! you have me thinking in the right direction now. The F# example makes me think I could get the message handler to call a delegate that handles the message(in C#), then i could just swap the delegate out at runtime with another message. The cluster idea sounds great too, will have to do some more reading. Thanks!
Bartosz Sypytkowski
@Horusiath
Jun 15 2015 16:34
@Gumpy in F# you can basically serialize a whole receiver expression and deserialize it on the other node, then compile and execute. You cannot do anything like that in C#. However I think it's not a good design to be applicable on the whole solution, rather on particular components in specific scenarios. In real life @bruinbrown advice is actually better
Andrew Skotzko
@skotzko
Jun 15 2015 17:11
@/all just finished an “intro to Akka.Cluster” video in case you're looking for a getting started w/ clustering >> https://www.youtube.com/watch?v=mUTKvGyxbOA
Bartosz Sypytkowski
@Horusiath
Jun 15 2015 17:11
@skotzko just finished watching it. Good job! :)
Andrew Skotzko
@skotzko
Jun 15 2015 17:14
@Horusiath thanks! We're gonna start adding a lot of docs in this area too
Bartosz Sypytkowski
@Horusiath
Jun 15 2015 17:19
We got quite good docs and learning materials area IMHO
Andrew Skotzko
@skotzko
Jun 15 2015 18:03
agree, meant around akka.cluster specifically, we're light there
Aaron Stannard
@Aaronontheweb
Jun 15 2015 20:57
@NeoDarque need to use a clustered router
@skotzko 's video has a lot of the details
but the Akka.NET addressing system requires you to explicit address messages to remote actors - clustering abstracts that via clustered routers
@varghesep one actor gets used over and over and over
in that sample
@varghesep a new FeedParserCoordinator is created for each feed being parsed, however - it's a stateful actor, and since the state correlates 1:1 to the URL being parsed it makes sense to use the child-per-entity pattern there
it can tell how much work it has to do for each parsing job
Aaron Stannard
@Aaronontheweb
Jun 15 2015 21:02
as for performance
you would absolutely want to throttle the rate at which async requests are kicked off in this sample
there's a point of diminishing returns beyond which some number of concurrent requests actually decreases throughput of the system
contention overhead of calls that need to join back on an app thread / state machines for async calls in memory / other forms of concurrency overhead in .NET start to outweigh the benefits of parallelizing the I/O
so that is a legitimate concern
Patrick Mohr
@kc7zzv
Jun 15 2015 22:57

I am using Akka, and in general everything works, but I ran into a problem where one message is being sent over and over to an actor when it should only be sent once. (App fails with OutOfMemoryException) It is actually the exact same message, not just the same content.

Is there a good way to try to find out where this message might be coming from? So far I'm using all local Actors. Nothing network related.

Aaron Stannard
@Aaronontheweb
Jun 15 2015 22:58
@kc7zzv you can try logging the Sender of the message
that'll give you the path of the actor responsible
the Sender property will be populated from within the actor receiving the message
Patrick Mohr
@kc7zzv
Jun 15 2015 23:06
Actually, I'm at a breakpoint in the debugger, so I'm looking at Context.Sender and Context.Self Both have a value of "akka://AppName/user/$b". I'm assuming that means I'm somehow managing to send the message back to myself, but I don't see how that's possible.
Aaron Stannard
@Aaronontheweb
Jun 15 2015 23:07
yep, you could be sending a message back to yourself
could you post the code from that receive method?
Patrick Mohr
@kc7zzv
Jun 15 2015 23:09
I'm using Reactive Extensions. I think this is the code you're talking about:
Receive<T>(m => subject.OnNext(m));
I was hoping I could somehow put a breakpoint at the place the message comes into the actor to catch a callstack of the sender.
Aaron Stannard
@Aaronontheweb
Jun 15 2015 23:11
I'm not familiar with Rx, but the symptom sure sounds like it's getting stuck in a loop where it sends itself the same message
what happens when OnNext is called?
Patrick Mohr
@kc7zzv
Jun 15 2015 23:12
Ya. It looks like a software bug, but this is basic enough that I'm assuming it's user error on my part.
Oh. I think I found the problem. Another actor is subscribing to the Reactive subject. That subscription calls:
_source.Subscribe(event => Context.Self.Tell(event));
Aaron Stannard
@Aaronontheweb
Jun 15 2015 23:17
ah, that would totally do it
messages need to be immutable :p
so two actors shouldn't be able to set subscriptions on eachother's messages
otherwise side effects like this can happen
Patrick Mohr
@kc7zzv
Jun 15 2015 23:18
The message is immutable, but I'm using Context.Self.Tell to send the message to a different Actor. Maybe "Context" isn't thread-safe since it's balling called from the thread of the original (looking) actor?
Aaron Stannard
@Aaronontheweb
Jun 15 2015 23:18
yeah, Context is thread-local, so you'll need to close over it
if you do that then it should work
Patrick Mohr
@kc7zzv
Jun 15 2015 23:19
Is this safe?
var self= Context.Self;
_source.Subscribe(event => self.Tell(event));
Aaron Stannard
@Aaronontheweb
Jun 15 2015 23:19
yep
the actorrefs are safe
Patrick Mohr
@kc7zzv
Jun 15 2015 23:20
Alright. Thank you for the help.
Aaron Stannard
@Aaronontheweb
Jun 15 2015 23:20
but the context is not thread safe
it changes on each message receive
it's meant to be internal to the actor
IActorRef is always thread safe though
and they're serializable
Patrick Mohr
@kc7zzv
Jun 15 2015 23:20
I had forgotten that since I was using it in a lamda, it had "escaped" the actor's thread.