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 sent in the opposite direction, still via the same ClusterReceptionist. The purpose is that the client should not have to know where the destination actors are located and it should use a single tcp connection to talk to the cluster.
In case of connection failures (detected with heartbeats) the client will establish a new connection to another receptionist. You can from the same frontend node create several ClusterClient instances and then they will most likely be associated with receptionists on different nodes, i.e. separate tcp connections for each client instance. I agree with previous recommendations that it is easies and most powerful to let the frontend nodes join the cluster instead, i.e. not use the cluster client for this use case. Regards, Patrik On Sat, Aug 15, 2015 at 7:46 PM, Johan Andrén <johan.and...@typesafe.com> wrote: > 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 nodes there should be no "tunneling" of messages. > > You can read more here: > http://doc.akka.io/docs/akka/2.3.12/contrib/cluster-client.html > > > -- > Johan Andrén > Typesafe - Reactive apps on the JVM > Twitter: @apnylle > > > On Saturday, August 15, 2015 at 1:24:24 AM UTC+3, tigerfoot wrote: >> >> 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. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw -- >>>>>>>>>> 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.
