A ClusterClient (outside the cluster) will talk to a ClusterReceptionist on
one node (in the cluster). All messages sent via that client instance will
be sent to the same ClusterReceptionist. The ClusterReceptionist will then
route the messages to destination actors (in the cluster). Replies are se
If there are many actor instances in the cluster with the same actor path
the message will be delivered to a randomly selected one, but you can
specify that the receptionist should prefer ones that are in the same
cluster node, so if you run one of the backend workers in each of the
cluster nod
aaand this is getting to the heart of my question.
If all the nodes (RESTful front-end and logic back-end) all belong to the
cluster as "first-class members" I can have listeners on each so I
basically know all the nodes in the cluster.
That way the RESTful nodes can use random/round-robin routi
Hi,
I agree that it strongly depends on your application. But it is an aspect
that one should consider when planning the architecture, that's why I
mentioned it.
best
Carsten
Am Mittwoch, 12. August 2015 10:40:20 UTC+2 schrieb Heiko Seeberger:
>
> Carsten,
>
> I don’t think your argument is v
Carsten,
I don’t think your argument is valid for a typical frontend/backend grouping of
a cluster where you have N frontend (HTTP) nodes and M backend nodes. Assuming
you use a reasonable strategy to distribute backend actors across the M backend
nodes, e.g. by using a cluster aware router or
Hi,
AFAIK the cluster client uses normal actor messaging from the client to the
cluster client to the distr-pub-sub to the final destination. No magic
knowledge in the cluster client that allows for direct communication.
As you probably won’t have 1000s of REST-nodes, I would make these part of
Hello,
I'm trying to understand the best way to interact with a cluster. For the
sake of conversation let's say I have a load-balanced tier of Akka HTTP
servers hosting REST endpoints. These endpoints will in turn send async or
sync messages to other actors within a cluster of back-end logic