ClusterSingleton router location and routing logic

[Shyam kumar Akirala]

Hi,

We are having several kinds of tasks and we wanted to control the number of actors spawned across the cluster to do a particular task. So we went with having many cluster singleton routers (1000s) in our project. All the routers are sitting on the oldest member of the cluster as mentioned in the docs, and all the messages to the actors under these routers are going through the oldest node and the oldest node became the bottleneck.

1. Is there anyway we can distribute the cluster singleton instances across the cluster so that the load would be shared.

2. Is it possible to extract the routing info from the oldest node, so that the requests would be forwarded directly to the actors without involving the router instance.

currently the messages are forwarded in this way: 

rotuerProxy -----------> routerInstance -------------> actor

wanted: 

routerProxy (has the routing info) --------------> actor

Cheers,

Shyam

[Rafał Krzewski]

Hi Shyam,

I think you need to use some kind of consistent hashing [1] scheme. Akka provides consistent hashing router [1]  also cluster sharding [2]  but the former AFAICT isn't aware of remoting / clustering (and thus rebalancing when cluster membership changes) and the latter is more heavy weight and geared towards Entity / Aggregate Root actors. 

Cheers,

Rafał

[1] https://en.wikipedia.org/wiki/Consistent_hashing

[2] http://doc.akka.io/docs/akka/snapshot/scala/routing.html#ConsistentHashingPool_and_ConsistentHashingGroup

[3] http://doc.akka.io/docs/akka/snapshot/scala/cluster-sharding.html

[Justin du coeur]

Sharding isn't *that* heavyweight, especially when compared to thousands of little Cluster Singletons.  Yes, you've got the ShardRegion actors involved, but that's not a big deal.

Personally, I would try to solve this one with Cluster Sharding -- it gets you the distribution more or less automatically, and if you control the namespace you can control how many sharded entities get created.  Indeed, if you've already got a scheme in place that defines the existing Singletons by some sort of clean ID and distributes work to them, switching that to Sharding instead seems like it ought to be straightforward.

--
>>>>>>>>>> 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+unsubscribe@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Shyam]

Thanks guys for the suggestions.

Thinking to solve this by having some external logic which spawns the actors of a particular task on few nodes of the cluster, and register these actors with routers which are available on all the nodes. So with this every node in the cluster has the routing logic, and whenever a node receives a message, it will forward the message to the remote router (lying on the same box) which in turn forwards one of the actors in the cluster.

To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.

[Patrik Nordwall]

Distributed PubSub can be used as a dynamic router.

/Patrik