When you join a cluster, are all actors nodes?

[lapming.lee]

If I have an actor system with one top-level actor under the user guardian, and under that top-level actor are multiple child actors.

1) When I join an cluster system:

A. are all the actors under this actor system automatically a node now? 

B. OR is the top-level actor the only node added to the cluster such that the entire actor system is ONE node? 

2) Should all the message passing go through the top-level actor under the user guardian? Or can I simply send it to any actor using the Event Stream?

[Heiko Seeberger]

The akka cluster is essentially a membership service for actor systems, not for actors. From the Cluster Specification  „A node could be a member of a cluster without hosting any actors.“

Actors can benefit from Akka Cluster via subscribing to cluster events. For example an actor could create child actors on every member node that joins the cluster, which is more or less what a cluster-aware pool router does.

Cheers

Heiko

--

Heiko Seeberger

Home: heikoseeberger.de

Twitter: @hseeberger

Public key: keybase.io/hseeberger

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[lapming.lee]

Hi Heiko,

I am reading up on cluster-aware pool router versus group router.  I am understand group router, but not so much with pool router.

Say if I have a seed node that has a cluster aware pool router.  When I create a new node with no actors in it, the pool router will automatically deploy routtees there. 

Here's the questions I have:

1) Then shouldn't I just build a monolithic application on a single node and use cluster aware pool routers to scale horizontally but starting up empty nodes?

2) If each node has a specific role (e.g. back-end, front-end,etc), I don't understand why one would deploy routtees in other nodes with different or same roles.  Can you give an example?  And what would they advantage be over group routers?

Regards,
Lap

[lapming.lee]

Hi Heiko, 

Say I have 2 micro service nodes: web, and authentication.  For each, they run their own Actor System and are hosted on their own physical machine.  

I want to connect the nodes together and be able to scale up the nodes when needed.  For example, if the web node sends a lot of authentication requests to the auth node and it can’t handle the volume, I need to be able to dynamically add a second auth node.

For both pool and group router, there are some parts which I don’t understand. 

For pool router, the router needs to send the routee actor to the target node.  So in this cause, does the web node send an actor to the auth node to connect with each other?  How does this work?

For group router, since the messages are routed with Actor Selection, there must be one routee node up at all times.   So for the example I gave: 

a) What if there is no auth node for the web node to connect to before or after the group router is created

b) What happens if I want to dynamically add a second auth node, can group router handle this situation?

Regards, 

Lap 

[Heiko Seeberger]

On 29 Sep 2015, at 06:10, lapming.lee <lapmi...@gmail.com> wrote:

Hi Heiko, 

Say I have 2 micro service nodes: web, and authentication.  For each, they run their own Actor System and are hosted on their own physical machine.  

I want to connect the nodes together and be able to scale up the nodes when needed.  For example, if the web node sends a lot of authentication requests to the auth node and it can’t handle the volume, I need to be able to dynamically add a second auth node.

Makes sense, but creating additional nodes is out of router scope.

For both pool and group router, there are some parts which I don’t understand. 

For pool router, the router needs to send the routee actor to the target node.  

No. On the remote system the classes need to be available, no classifies are transmitted.

So in this cause, does the web node send an actor to the auth node to connect with each other?  How does this work?

For group router, since the messages are routed with Actor Selection, there must be one routee node up at all times.   So for the example I gave: 

a) What if there is no auth node for the web node to connect to before or after the group router is created

Then the group router has zero routees.

b) What happens if I want to dynamically add a second auth node, can group router handle this situation?

Sure. The cluster aware group router will dynamically adjust the set of routees.

[lapming.lee]

Hi Heiko, 

After reading a bit more about Akka remote, I have a much better understanding of when to use pool and group routers.  You mentioned here:

For pool router, the router needs to send the routee actor to the target node.  

No. On the remote system the classes need to be available, no classifies are transmitted.

So in this case does that mean the actors that will be deployed need to be in both the local and the remote system.  When the router is deployed, it only connects to the same actor class in the remote system. 

Another question that I have is how can the microservices message each other.  On external systems, you use a REST interface, but in an akka cluster/remote  that seems a bit overkill.  Would you use case classes in this case?  Whereby you have the same case class defined in both the local and remote system so they can message each other with actors?   Would you use versioning for case classes as well?  

Regards, 

Lap

[lapming.lee]

Found the answer : ) 

1) Yes, the class need to be both the remote and local system.  Pool routers only maps the actors together.  It simple sends an instruction via props to the remote system to create an actor for it.  Then maps the actor ref back to the local system. 

2) Microservices can message each other through a shared protocol with case classes.  Case classes can be added without versioning.