Hi, another aspect to consider is message volume. My experience with the cluster client is that the communication might become unstable under high load. The reason is, AFAIK, that the communication between actor systems is done via a single TCP connection and all messages go via that connection. Since the cluster client uses normal messaging, as Heiko also pointed out, this will put a lot of pressure on that TCP connection. This is also true within the cluster if you have the REST API nodes running as members. Since all messages between actors go via a single connection (together with the internal cluster messages), that connection becomes a bottleneck and the cluster might even become unstable.
I personally would always prefer to have the REST API running in the same actor system as the actors (if able) and try to reduce load on the akka remote layer, and route HTTP traffic to the correct nodes via a proxy. But it depends on the problem and the overall architecture if it's feasible or not. And the effects I desribed only happen under very high load, i.e., when the REST API is constantly hit by several processes and each process triggers a message to some other node. best Carsten Am Montag, 10. August 2015 22:00:18 UTC+2 schrieb tigerfoot: > > 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 nodes as > needed by role. > > I can see two approaches for this. I can have my REST nodes outside the > cluster and use the cluster client, which the docs explains uses a > receptionist, to send messages to exposed actors within the cluster. > Alternatively I can have my REST nodes as full members of the cluster > along with the actors/nodes providing the back-end logic. > > I like the separation of the client/receptionist approach but am worried > that the receptionist becomes a choke-point. Does every message send from > the cluster client on the REST tier go through the given receptionist > (which would be a choke point) or is the receptionist only used as an event > listener on the cluster for the client (not a choke point)? If the latter > is true the cluster client maintains sufficient knowledge to randomly > select nodes in the cluster without bothering the receptionist on every > request. I'm hoping that's the way it works. > > The second approach (all one big cluster) is less appealing > architecturally but is certainly simple enough to implement. > > Can anyone help clarify the relationship between the cluster client and > the receptionist? > > Thanks! > Greg > -- >>>>>>>>>> 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+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
