These are chat archives for akkadotnet/akka.net

5th
Feb 2016
Hyungho Ko
@hhko
Feb 05 2016 07:45
        _rendezvousWorkersRouter = Context
                    .ActorOf(Props.Create(() => new RendezvousWorker())
                            .WithRouter(new RoundRobinPool(3))
                            .WithSupervisorStrategy(new OneForOneStrategy((excep) =>
                                {
                                    return Directive.Restart;
                                }))
                        , "RendezvousWorkersRouter");
blob
I think that $b(actor) is only restarted because of OneForOneStrategy.
$c and $d are not supposed to is restarted.
but. $c and $d are also restarted with $b.
why?
Bartosz Sypytkowski
@Horusiath
Feb 05 2016 07:47
/cc @rogeralsing
Roger Johansson
@rogeralsing
Feb 05 2016 07:52
Routers escalate to router parent by default and if the parent Restarts the router, all children will also reboot
You have to supply a new one for one to the actual router to get the behavior you want
Hyungho Ko
@hhko
Feb 05 2016 07:55
.WithSupervisorStrategy(new OneForOneStrategy((excep) =>
{
return Directive.Restart;
}))
this means that router do not escalate to router parent.
is it right?
I think this means router has OneForOneStrategy.
Yin Zhang
@melcloud
Feb 05 2016 08:24

@hhko The supervision strategy of the router actor can be configured with the supervisorStrategy property of the Pool. If no configuration is provided, routers default to a strategy of “always escalate”. This means that errors are passed up to the router's supervisor for handling. The router's supervisor will decide what to do about any errors.

Note the router's supervisor will treat the error as an error with the router itself. Therefore a directive to stop or restart will cause the router itself to stop or restart. The router, in turn, will cause its children to stop and restart.

WithSupervisorStrategy is not routers supervisor strategy
blob
Hyungho Ko
@hhko
Feb 05 2016 08:27

class RendezvousListener : ReceiveActor
{
protected override SupervisorStrategy SupervisorStrategy()
{
return new OneForOneStrategy((excep) =>
{
return Directive.Restart;
});
}

private void CreateRendezvousWorkersRouter()
{
    _rendezvousWorkersRouter = Context
                .ActorOf(Props.Create(() => new RendezvousWorker())
                        .WithRouter(new RoundRobinPool(3))
                        //.WithSupervisorStrategy(new OneForOneStrategy((excep) =>
                        //    {
                        //        return Directive.Restart;
                        //    }))
                    , "RendezvousWorkersRouter");
}

}

it's the same.
RendezvousListener is router's parent.
RendezvousListener has OneForOneStrategy.
Yin Zhang
@melcloud
Feb 05 2016 08:28
The roundRobinPool has a property for 1 supervisorstrategy `
Hyungho Ko
@hhko
Feb 05 2016 08:31
I see. but this property has only get.
Hyungho Ko
@hhko
Feb 05 2016 08:36
@melcloud thank you very much.
I changed my code. below.
        _rendezvousWorkersRouter = Context
                    .ActorOf(Props.Create(() => new RendezvousWorker())
                            .WithRouter(
                                new RoundRobinPool(3)
                                    .WithSupervisorStrategy(new OneForOneStrategy((excep) =>
                                    {
                                        return Directive.Restart;
                                    }))
                            )
                            //.WithSupervisorStrategy(new OneForOneStrategy((excep) =>
                            //    {
                            //        return Directive.Restart;
                            //    }))
                        , "RendezvousWorkersRouter");
i solved this problem. RoundRobinPool has it's 'WithSupervisorStrategy' method. ^^;
JaspritBola
@JaspritBola
Feb 05 2016 10:00
@voltcode I wonder if it is because you are auto-downing? If it's not downed the node can become reachable again.
Raymen Scholten
@raymens
Feb 05 2016 10:07
What's the easiest way to handle 1 message each second without blocking any other actors/threads etc.?
Bartosz Sypytkowski
@Horusiath
Feb 05 2016 10:07
@raymens send that message inside schedule?
Raymen Scholten
@raymens
Feb 05 2016 10:08
@Horusiath multiple actors send message to that actor. You would advise to place an actor between them that sends messages inside a scheduler?
Bartosz Sypytkowski
@Horusiath
Feb 05 2016 10:09
why not? :)
this is called throttler pattern or something like that
Raymen Scholten
@raymens
Feb 05 2016 10:10
But I guess that hasn't been ported
Thanks :+1:
Bartosz Sypytkowski
@Horusiath
Feb 05 2016 10:11
nope, contrib namespace hasn't been ported in general
Yin Zhang
@melcloud
Feb 05 2016 10:19
@hhko It got me for a while as well. Glad it helps. :smile:
Roger Johansson
@rogeralsing
Feb 05 2016 12:03
@raymens if you want to throttle an actor to only receive once every sec. then the easiest way is to use async await tbh..... Receive<MyMessage>(async m => dostuff; await Task.Delay(...)); that is nonblocking and keeps actor concurrency intact
not as sophisticated as the throttling actor on the JVM, but it does the trick if that is all you need
Raymen Scholten
@raymens
Feb 05 2016 12:34
@rogeralsing thanks but I already implemented one with the scheduler. I'll keep that in mind when I have to implement another one
Alex Achinfiev
@aachinfiev
Feb 05 2016 13:45
@rogeralsing Is using Receive<MyMessage>(async m => dostuff; await Task....)) encouraged again? I know that in first versions you had support for this model but then removed it in favour of using PipeTo. Is this something that came back in as an acceptable practice? Thanks
Roger Johansson
@rogeralsing
Feb 05 2016 13:46
@aachinfiev it depends on the usecase. one needs to understand the implications of suspending the mailbox of an actor, which is exactly what the async await support does
for example, lets say that you have an async handler that issues an Ask to itself or another actor that in turn sends messages back to you... then you will have a deadlock, its still non blocking code, but the actor will deadlock as it is paused on the await operation of the Ask
PipeTo does not suffer from that as it just continues processing messages while the continuation completes..
Alex Achinfiev
@aachinfiev
Feb 05 2016 13:48
@rogeralsing Yes, you used to have re-entrant mode with async before which is gone now to address the deadlock issue.
Roger Johansson
@rogeralsing
Feb 05 2016 13:48
So the async await support works as expected, there are no known bugs around it, but it is easy to mess up if you dont "get it"
Alex Achinfiev
@aachinfiev
Feb 05 2016 13:48
I was just wondering if that was back in (with re-entrant) behaviour
Roger Johansson
@rogeralsing
Feb 05 2016 13:49
no the re-entrant was way to hard for most people to deal with
so the only support we have left makes async await behave exactly as a normal actor, but with non blocking awaits
Alex Achinfiev
@aachinfiev
Feb 05 2016 13:49
Got it. Good to know.
Btw. I submitted a pull request for Akka.Persistence.Cassandra to bump it to use 1.0.6 version of Akka & Akka.Persistence, but latest dev branch has certain specs failing and my pull request is in the failed check mode now. Do you typically let that block PRs until dev branch is resolved?
Alex Achinfiev
@aachinfiev
Feb 05 2016 13:58
@rogeralsing If you use immutable message, where do you typically see the effects of that or run into an issue? Is that a hard requirement or a soft one? Is there an example that would demonstrate the failure or impact if message was mutable? Thanks.
Roger Johansson
@rogeralsing
Feb 05 2016 14:00
@aachinfiev its a soft requirement, the reason you shouldnt use mutable messages is because that could be used to mutate data passed to two or more actors
which could lead to race conditions
lets say you send an "order" to two actor for processing.. and one of the actors starts to mutate that order object, then those changes will be visible to the other actor at the same time, making that actor racy
Alex Achinfiev
@aachinfiev
Feb 05 2016 14:06
We normally don't perform that operation but what we do do sometimes is on reply to sender we may send some tracking id on a returning object. And for cases where same object needs to go to multiple actors we clone it. At least in couple places where we needed that.
Alex Achinfiev
@aachinfiev
Feb 05 2016 14:13
Is there a certain limit (maybe best practice) on how many direct children an actor can have? We were using example of AggregateCoordinator and AggregateRoot for event sourcing style model and during import of say 100k entities you end up with actor with that many children. When it would get to around 80k it would stall and some requests wouldn't even get through to the actor but it doesn't crash (restart is not invoked).
When I put code in child to auto shutdown after 10s of inactivity that keeps number of children around 5-6k and things go through
EGirardi
@EGirardi
Feb 05 2016 15:52
If I have a router setup and it in turn has 5 worker Actors, I want to do some load tests and log all the calls that went to the router to see that the workers received them & verify that indeed more than one worker is doing the work. How can I name the workers ? For example in my log file it just shows the name of the Actor Class "2016-02-05 10:50:02.2828|INFO|HttpListenerServer.CustomerFunctionsActor" but not the specific worker that logged it. Should I even care ?
Garrard Kitchen
@garrardkitchen
Feb 05 2016 16:40
Re clustering: If you shutdown (terminate()) an actor system on a particular server (think stopping a windows service), if that same actor system is being used elsewhere (on other servers) would it be shutdown on those servers too?
Marc Piechura
@marcpiechura
Feb 05 2016 16:49
@EGirardi you can use a group router
Marc Piechura
@marcpiechura
Feb 05 2016 17:16
And for the log entry I think you need to change the logging template
Aaron Stannard
@Aaronontheweb
Feb 05 2016 17:43
@voltcode nodes will attempt to automatically rejoin the cluster in both directions - but it's your responsibility to make sure that your firewall and hosting setup allows that
cluster nodes should have free visibility / connectivity with each other
since they're all meant to be peers
not like a client-server architecture where connectivity can only be established in one direction (client --> server)
the idea behind the bootstrapper is being able to look up the ip / ports that all nodes can see from a third party service
Azure Runtime API, AWS SDK, some hand-rolled stuff, etc...
and then use that to start your nodes
the long and the short of it is: you will end up having to use one 100% of the time anyway
static HOCON configurations aren't going to be able to tell you which IP is visible on your private network