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 routing to role-selected back-end nodes. That should work well, and typically you have dozens, not hundreds or thousands of nodes.
All good, but I'm curious about the cluster client. If I use the client then the RESTful nodes are *not* members of the cluster and can't listen for up/down events. I'm kinda hoping that within the client code it basically does this so that I ask the client (running on a REST node), "Hey--gimme a 'logic-1' node to talk to" and it uses some allocations scheme to give me a connection. That'd be very cool and hoped-for behavior. It's perfectly fine if the dedicated/specified connection to the receptionist is merely to listen for cluster events--NOT as a pass-thru for message traffic. It would not be so cool if all messages pass through the dedicated connection to the cluster client/receptionist. That would definitely be a bottleneck Anyone know what behavior cluster client uses here? Thanks! On Wednesday, August 12, 2015 at 4:38:16 AM UTC-5, Carsten Saathoff wrote: > > 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 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 cluster >> sharding, on average the communication load between each of the N frontend >> nodes should be distributed evenly across the M backend nodes. So instead >> of a single connection the load is distributed across M. >> >> Cheers >> Heiko >> >> >> On 12 Aug 2015, at 09:01, Carsten Saathoff <car...@kodemaniak.de> wrote: >> >> 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+...@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. >> >> >> -- >>>>>>>>>> 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.
