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 the cluster. Are you aware of cluster roles? That way you could designate some nodes for “rest" and others for something like “backend” and get something sort of two sub-clusters. BTW, what’s a sync message? In Akka all communication is async. Heiko -- Heiko Seeberger Home: heikoseeberger.de <http://heikoseeberger.de/> Twitter: @hseeberger <https://twitter.com/hseeberger> Public key: keybase.io/hseeberger <https://keybase.io/hseeberger> > On 10 Aug 2015, at 22:00, tigerfoot <gzol...@gmail.com> wrote: > > 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/ <http://akka.io/docs/> > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > >>>>>>>>>> <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 > <mailto:akka-user+unsubscr...@googlegroups.com>. > To post to this group, send email to akka-user@googlegroups.com > <mailto:akka-user@googlegroups.com>. > Visit this group at http://groups.google.com/group/akka-user > <http://groups.google.com/group/akka-user>. > For more options, visit https://groups.google.com/d/optout > <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.
