These are chat archives for akkadotnet/akka.net

22nd
Jun 2016
Ricky Blankenaufulland
@ZoolWay
Jun 22 2016 09:09

Hmm, I am wondering. Scenario is cluster but could be remote as well. Why do I need an actual type of an actual if that Actor is need deployed locally? I am creating the router to some remote actors like this:

var props = Props.Create<DummyActor>().WithRouter(FromConfig.Instance);
var ref = this.actorSystem.ActorOf(props, name);

Sure thing is that DummyActor here does not matter because on the remote nodes there will be another type used for that referenced actor. So why do I require it at all?

Bartosz Sypytkowski
@Horusiath
Jun 22 2016 09:10
@ZoolWay there is Props.Empty if I remember correctly, but haven't used it in such scenario
Ricky Blankenaufulland
@ZoolWay
Jun 22 2016 09:11
I have tried it but there will never be an actor/router created and all Tells will go into the void
I would expect something like a Props.RemoteOnlyActor maybe
sure thing is if I change the HOCON configuration to allow local deployment DummyActor will be used but that would not be a valid scenario in my case.
Chris G. Stevens
@cgstevens
Jun 22 2016 15:12

What would be the cause or is this normal that I get a DeathWatchNotification as a DeadLetter for each Actor that my router created.
So if I have tallyRouter actor configured for nr-of-instances = 100 I get 100 DeathWatchNotification which increases counter.
I need to explain to someone who might be looking at the counters and why I have thousands and thousands of them.
It appears to happen after I get the <Terminate> message which I should as I do a Context.Stop(tallyRouter).

Message: <DeathWatchNotification>: [akka://MyService/user/jobmaster/monkey/workercoordinator/tally/$h], ExistenceConfirmed=True, AddressTerminated=False
Sender: akka://MyService/user/jobmaster/monkey/workercoordinator/tally
Recipient: akka://MyService/user/jobmaster/monkey/workercoordinator/tally

Aaron Stannard
@Aaronontheweb
Jun 22 2016 15:47
@cgstevens ah, this is due to a bug that we've fixed as part of 1.1
long story short: when a parent terminates it's only supposed to finish terminating after all of its children have finished terminating
in all versions of Akka prior to 1.1 this was not enforced
so parents could, and usually would, terminate before their children
so they wouldn't be around to handle the death watch notifications
Chris G. Stevens
@cgstevens
Jun 22 2016 16:21
@Aaronontheweb Thanks for the info! I have been trying to figure out if I am doing something wrong.
I wired up Application Insights and let it run NOT KNOWING that I was generating so many data points that I hit the free limit in about 15 hours.
I learned not to do that! So now not running every job but just 1.. at 1 time and then reviewing results as well as put in ActorPerformanceCountersMonitor.
So... could I .Stop the children before the parent to avoid?
Arjen Smits
@Danthar
Jun 22 2016 17:53
@cgstevens there is no way to get that waterproof in "user-space" sort of speak, without dropping to very low level actor implementations, but then you introduce other problems you need to think about.
So you really need the bugfix @Aaronontheweb was talking about.
Chris G. Stevens
@cgstevens
Jun 22 2016 18:29
@Danthar If it is fixed in 1.1 that should be fine. Not sure what is evolved in the bug fix but...
I need to answer "Do my actors really need to be stopped and recreated every time?"
If they don't then this wouldn't be an issue in this app.
Arjen Smits
@Danthar
Jun 22 2016 18:53
You create an actor for every job right ?
Having the actor lifetime coincide with your lob lifetime is the most natural model.
You could work with pools of job processors on each node. Where you post work to a node and have that node delegate that work to a worker in the pool. Basically you'd apply a resourcepool pattern approach to your job actors. Taking one out of the pool to have it handle work, and letting it fall back into the pool when its done.
But that would be alot of work for something that could be handled far more elegant when you take the 'simple' approach.
Aaron Stannard
@Aaronontheweb
Jun 22 2016 19:04
@cgstevens the bugfix required me to rewrite how mailboxes, dispatchers, and actor cells work
and how we start top-level actors
just to give you an idea
lol
plus a big previous fix for how we deal with system messages
@alexvaluyskiy man, this consistent hash routing spec is failing constantly but I'm pretty sure that's addressed in your router rewrite
Chris G. Stevens
@cgstevens
Jun 22 2016 20:19
blob
@Aaronontheweb Thanks for the info!
It was actually pretty easy change what I had and not stop by actor but just to reuse them.
You can see here that the DeadLetters basically don't happen after I made a few changes.
Scott Martin
@Scott__Martin_twitter
Jun 22 2016 20:24
Can anyone point me in the direction of how to use Context.ActorSelection() from an async event handler? Or a better alternative? I am trying to receive an event from a socket and send an Tell() to my authActor.
Aaron Stannard
@Aaronontheweb
Jun 22 2016 20:26
@Scott__Martin_twitter if you're receiving an event external to an ActorSystem
just use ActorSystem.ActorSelection instead
even better - bake an IActorRef to the actor you want to message directly into the event handler
and then just use Tell
that's easier to test, debug, and more performant
Scott Martin
@Scott__Martin_twitter
Jun 22 2016 20:28
@Aaronontheweb Ok, I was trying to not have to make all of my "client" actors have an ActorRef to AuthActor. Is it better to just pass the AuthActor as a Singleton?
Aaron Stannard
@Aaronontheweb
Jun 22 2016 20:29
if the AuthActor is a top-level actor
Scott Martin
@Scott__Martin_twitter
Jun 22 2016 20:29
yes
Aaron Stannard
@Aaronontheweb
Jun 22 2016 20:29
then you can just stash a reference to it in a static class somewhere
and have actors fetch a reference from there
it's not as "clean" as passing that in as an argument via the constructor or via a message
but IMHO it's the best compromise
especially if that actorref needs to be shared between non-actor code (socket handlers, MVC controllers) and actors too
Scott Martin
@Scott__Martin_twitter
Jun 22 2016 20:30
Got it, would an IoC make it easier?
Aaron Stannard
@Aaronontheweb
Jun 22 2016 20:31
then you'd have two problems
as you'd need to bind your singleton IActorRef and distinguish it from any other IActorRefs you might need to pass around to other objects
but I've done that before too
needed it to inject actor references into controllers
Scott Martin
@Scott__Martin_twitter
Jun 22 2016 20:32
ah, good point
Is there a common pattern for injection messages from outside the ActorSystem?
Aaron Stannard
@Aaronontheweb
Jun 22 2016 20:33
you can always pass a message to any IActorRef from anywhere
Scott Martin
@Scott__Martin_twitter
Jun 22 2016 20:33
For now the static ref isn't so bad as it is to only maintain backwards compatibility for the time being.
Aaron Stannard
@Aaronontheweb
Jun 22 2016 20:33
and any top-level actors declared via ActorSystem.ActorOf are easily passable to external contexts
Scott Martin
@Scott__Martin_twitter
Jun 22 2016 20:34
@Aaronontheweb Thank you for the information!
Aaron Stannard
@Aaronontheweb
Jun 22 2016 20:39
@alexvaluyskiy figured out that consistent hash router race condition
it's a side-effect of having that actor start as a RepointableActorRef
if the actor cell doesn't start right away (talking like nanoseconds here)
the call to check to see how many children the router has, the first call, will fail
because the actor startup is asynchronous now
I think I can fix that
Aaron Stannard
@Aaronontheweb
Jun 22 2016 20:46
(TL;DR; it's an issue with how the test is designed)
Aaron Stannard
@Aaronontheweb
Jun 22 2016 20:56
added a fix just now akkadotnet/akka.net#2112