These are chat archives for petabridge/akka-bootcamp

23rd
Jan 2016
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:15
@david-rodriguez right now there's just that one
basically you use clustered routers primarily for remote communication with other cluster nodes
although there are other ways of doing it
inside the Akka.NET repo itself we have some cluster samples that show off how to do manual communication inside an Akka.NET cluster
David Rodriguez
@david-rodriguez
Jan 23 2016 00:16
Do I need to use deployments (in the config) if I am interacting with remote actors in a cluster?
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:16
no
you can use group routers
or remote actor selections
to communicate with pre-existing actors
that reside on other nodes in the cluster
which is how inside WebCrawler the web service communicates with tracker
via a group router
a clustered group router is basically just an actor that routes messages to the same ActorSelection but for each node that joins
and becomes a member
David Rodriguez
@david-rodriguez
Jan 23 2016 00:17
Simliar to this: Context.ActorSelection("akka://ProductSystem/user/*/NewOrderActor").Tell(order)
?
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:18
yes, correct
David Rodriguez
@david-rodriguez
Jan 23 2016 00:19
If I just want to communicate with a single node, I would remove the asterisk?
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:19
for communicating directly with a remote node though you'd need to include the protocol scheme and IP:port
would look like this
David Rodriguez
@david-rodriguez
Jan 23 2016 00:19
But wouldn’t that break the location transparency of the cluster?
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:20
Context.ActorSelection("akka.tcp://ProductSystem@localhost:8081/user/Foo")
yep, which is why you use a group router instead
David Rodriguez
@david-rodriguez
Jan 23 2016 00:20
I’m extremely new to Akka, so can you point me to an example of a group router?
this is where we defined a group router via configuration
David Rodriguez
@david-rodriguez
Jan 23 2016 00:20
Ah
deployment {
                                /tasker {
                                    router = consistent-hashing-group
                  routees.paths = ["/user/api"]
                                    virtual-nodes-factor = 8
                                    cluster {
                                            enabled = on
                                            max-nr-of-instances-per-node = 2
                                            allow-local-routees = off
                                            use-role = tracker
                                    }
                                }                
                            }
pardon the weird indenting
David Rodriguez
@david-rodriguez
Jan 23 2016 00:21
I’m trying to understand the use of the CommandProcessor - what’s its purpose?
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:22
routees.paths is the stub of your actor selection
ignore it - was a workaround for a bug with cluster routers early on
it doesn't even get used anymore
basically group routers were broken but pool routers weren't
David Rodriguez
@david-rodriguez
Jan 23 2016 00:22
Ah.
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:22
so I hacked a pool router to deploy an actor onto the node I wanted to communicate with
got rid of it after 1.0.1/1.0.2 when we fixed it
but never deleted that old class
David Rodriguez
@david-rodriguez
Jan 23 2016 00:24
So, would I setup something like this to communicate with an actor in the cluster? ActorSystem.ActorOf(Props.Create(() => new SignalRActor()), "signalr");
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:26
csharp
var router = ActorSystem.ActorOf(Props.Empty.WithRouter(FromConfig.Instance), "tasker");
like that
that would create the group router that will dynamically find new nodes
and in the case of this particular piece of HOCON
I specified that it should only find nodes with a role of "tracker"
which is a piece of meta-data that you declare in your Akka.Cluster HOCON configuration section
David Rodriguez
@david-rodriguez
Jan 23 2016 00:27
I have the cluster running using Lighthouse and the cluster is working correctly.
Just trying to get the client (Web API) and the node to work together.
And I read this guide to figure out to communicate with the node: https://petabridge.com/blog/when-should-I-use-actor-selection/
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:29
those guidelines are pretty good
I should add something for talking about cluster communication
David Rodriguez
@david-rodriguez
Jan 23 2016 00:29
So if I understand Akka and the guide correctly, when I send a message via:
Context.ActorSelection(ActorPaths.AuthenticatorActor.Path).Tell(message);
A node will receive the message, process it and return a response which will be sent back to the client.
The client must have an actor configured to receive the node response.
Is this correct?
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:32
that's correct
an actor needs to exist at the path defined by ActorPaths.AuthenticatorActor.Path
however, once an actor replies back you can just use actor references
because the Sender will be a transparent IActorRef back to the remote actor who sent the message
no need to use an ActorSelection after the first reply
David Rodriguez
@david-rodriguez
Jan 23 2016 00:33
Will all subsequent replies be sent to the same node?
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:33
it's all 1:1 unless the actor path is a wildcard
then it will be one to many
David Rodriguez
@david-rodriguez
Jan 23 2016 00:34
Ah
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:34
followed by a sequence of 1:1 messages back
David Rodriguez
@david-rodriguez
Jan 23 2016 00:34
Perfect.
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:34
np - this stuff is a trip once you first get started with it
but these are good questions
:+1:
David Rodriguez
@david-rodriguez
Jan 23 2016 00:35
The client used is a stateless RestAPI so must the ActorSelection be used per request?
And right now, we’re only keeping the ActorSystem in a static object.
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:36
you could resolve the ActorSelection once and cache it into a static IActorRef
or just keep using it
performance difference would be trivial
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:36
yes
David Rodriguez
@david-rodriguez
Jan 23 2016 00:37
But isn’t this just a workaround as per the comments?
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:37
ActorSelection is generally less efficient than IActorRef
but if all you're doing is using it to pipe data somewhere else
it's not a big deal
David Rodriguez
@david-rodriguez
Jan 23 2016 00:37
Ok
That makes sense.
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:37
the reason we scare people off from abusing is because they do stuff like use actor selections EVERYWHERE
and explicitly address messages to all nodes
err, all actors
totally defeats the purpose of location transparency
David Rodriguez
@david-rodriguez
Jan 23 2016 00:38
Agree
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:38
and is extremely inefficient, tightly coupled, and nearly impossible to test correctly
but using it for something purpose built like making sure that a dedicated actor in a remote service always gets the message
David Rodriguez
@david-rodriguez
Jan 23 2016 00:38
Our current application is loosely coupled but we’re struggling with scalability - which is why we’re adopting Akka.
Aaron Stannard
@Aaronontheweb
Jan 23 2016 00:38
from a node that's not really using actors
you may want to attend our clustering training we're doing next week: https://petabridge.com/training/akka-clustering/#fndtn-us_eu
it's not free, but it will save you a tremendous amount of time with the architectural stuff on this
David Rodriguez
@david-rodriguez
Jan 23 2016 00:39
Right now we’re in crunch mode trying to get this to work but after this hurdle, I will be attending every course.
Also, my goal is to hire Petabridge to bless our implementation after our launch.
Give us the good, bad and ugly so I greatly appreciate your time.