0

It seems this is where routers come into play according to the docs (https://getakka.net/articles/clustering/cluster-routing.html) and the various tutorials and code samples I have read. What seems to be omitted though is how to have NodeB invoke an actor located on NodeA. Under a microservice system, the "service/actor" that does the work would likely be located on another node entirely.

So it seems I would need to place a router on each node in the cluster. I am interested in using a broadcast-pool but with Pool based routers, per the docs, they deploy to their routees:

Clustered Pool routers differ from Group routers in that they deploy their routees remotely onto their target nodes, versus routing messages to pre-defined actor paths that may or may not exist on the remote machines.

So it would seem that duplicating pool based routers would also duplicate the deploys across the nodes.

So that seems to imply that you only want one pool based router to avoid this deployment duplication? I guess max-nr-of-instances-per-node would limit that?

In my case I want to use roles to assign what is available where:

akka {
    actor{
        provider = cluster
        deployment {
            /deviceA {
                router = broadcast-pool 
                cluster {
                    enabled = on
                    allow-local-routees = off
                    use-role = deviceA
                }
            }
        }
    }
}

Beyond that, if my actor is running on NodeB and wishes to invoke another actor located on another node (microservices), if a router is not defined on NodeB would I use ActorSelection to get a handle on the router? I assume I would need the full path to where the router is defined to be able to do that: akka.tcp://...

I guess my other alternative would be to configure NodeB to know where certain nodes are

  Context.ActorSelection("akka.tcp://MySystem@locationOfRouter:8000/user/deviceA").Tell(new MyMessage("UsefulInformation"));

I suppose that NodeB already needs to know where to connect to the seed nodes, so in that case I would have the full path and I could just define the router on the seeds, and then use actor selection to get a handle on those routers, which would necessitate hardcoding those paths. I assume that approach is less desirable.

I could also be doing things completely wrong, and maybe this approach would be better: Distributed Publish Subscribe in Cluster

https://getakka.net/articles/clustering/distributed-publish-subscribe.html

Since it specifically states that:

How do I send a message to an actor without knowing which node it is running on?

That seems a bit like shouting into the void and hoping for the best though, especially if something needs a reply, for example, calling an actor that would fetch some additional data to return to the sender.

AJ Venturella
  • 4,742
  • 4
  • 33
  • 62
  • Did you find out how to solve what you mentions? I think I'm in a similar situation of confusion. – Wasp Oct 08 '18 at 13:25
  • So what I ended up doing was using `ActorSelection` as noted above. I didn't bother with any deployment (auto deployment) at all or routers. My use case was very simple though. You can also ask the cluster for all it's nodes and filter based on roles to get the address of 1 specific node. I ended up writing a WebUI for that purpose. I also learned that you can use PubSub, and supply a "sender:" to the `Tell` if you need to get a reply. – AJ Venturella Oct 08 '18 at 23:10
  • Ok, makes sense. I also did more investigation and figured out better (I think...) how to use routers and how selections work across the cluster. – Wasp Oct 12 '18 at 13:28

0 Answers0