Thanks for the input Andre. I actually got quite engrossed with this issue that I ran into since the last two days and what I’m tending towards is that ActorRef based messaging is basically better as a fire-and-forget medium, where you send a message but don’t wait for an immediate reply. Also, ask involves us to have an implicit timeout value at the ask-ing side which may not work well in cases where the remote actor has its own task queuing etc.
I’ll go through all of the possible docs to understand Akka-remoting and its use cases better. Our workaround now is to deploy single instances of each of the applications that implement ask, and later refactor them to a more reliable communication mechanism. Moreover, are you aware of any inherent benefits of using ask over any of the other communication mechanisms you’ve mentioned? Thank you for clarifying this. Best, Ashesh Ambasta www.asheshambasta.com > On 09 Sep 2015, at 15:08, Akka Team <akka.offic...@gmail.com> wrote: > > Hi Ashesh, > > These pages describe the addressing scheme: > > http://doc.akka.io/docs/akka/2.4.0-RC2/general/addressing.html > <http://doc.akka.io/docs/akka/2.4.0-RC2/general/addressing.html> > http://doc.akka.io/docs/akka/2.4.0-RC2/general/remoting.html#Peer-to-Peer_vs__Client-Server > > <http://doc.akka.io/docs/akka/2.4.0-RC2/general/remoting.html#Peer-to-Peer_vs__Client-Server> > > (also describe how to separate bind-port from external logical port - this is > only available in 2.4-RC2, not in the 2.3 series). > > In general an ActorRef represents a certain actor on a certain machine, not a > certain actor on a pool of machines - i.e. it does not work well with > external load balancing. There are routers though that solve this at the app > level: http://doc.akka.io/docs/akka/2.4.0-RC2/scala/routing.html > <http://doc.akka.io/docs/akka/2.4.0-RC2/scala/routing.html> > > If you really want to use external load balancing then you cannot use > Remoting with it. In this case you can use any of the other technologies that > Akka provides for communication between systems (actor or not): > - akka.io <http://akka.io/> for actor based TCP and UDP APIs > (http://doc.akka.io/api/akka/2.4.0-RC2/#akka.io.package > <http://doc.akka.io/api/akka/2.4.0-RC2/#akka.io.package>) > - akka.streams.io <http://akka.streams.io/> for stream based TCP and UDP > APIs > (http://doc.akka.io/api/akka-stream-and-http-experimental/1.0/#akka.stream.io.package > > <http://doc.akka.io/api/akka-stream-and-http-experimental/1.0/#akka.stream.io.package>) > - Spray, for actor based HTTP (http://spray.io <http://spray.io/>) > - Akka HTTP > (http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0/scala/http/index.html > > <http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0/scala/http/index.html>) > > Remoting is just one of the possible solutions with a certain set of > trade-offs. You can even mix-and-match, for example an internal set of > systems form a cluster A, using remoting between them, another set of systems > form cluster B, using remoting between them, and then A and B communicate via > HTTP using load balancing. > > -Endre > > On Wed, Sep 9, 2015 at 2:47 PM, Ashesh Ambasta <ashesh.amba...@gmail.com > <mailto:ashesh.amba...@gmail.com>> wrote: > In my case, this is the situation: > I’m using Marathon to execute Docker containers with my Akka applications. > Now, Marathon, along with Marathon-DNS assigns each set of instances of a > running service a DNS, so something like app-a.marathon.mesos (if marathon is > running inside mesos). Now, every request to app-a.marathon.mesos goes > through an LB which can go to any one of the running instances of app-a. > > Now, app-a wants to ask an actor on app-b and app-b replies to the > `sender()`, which should be the actor on `app-a`. Now I’m in a soup because: > I run app-a and bind it to listen for remoting on either the IP of the host > its container is running on, in that case, only the reply part works > correctly, because the asking actor is associated correctly. > I run app-a and ask it to bind to `app-a.marathon.mesos`, in which case, I > see the sender on `app-b` as `application@app-a.marathon > <mailto:application@app-a.marathon>.mesos` which is correct but it doesn’t > have a specific reference to where the message came from. > I think the assumption is that the binding address per actor system is unique. > > Best, > > Ashesh Ambasta > www.asheshambasta.com <http://www.asheshambasta.com/> > >> On 09 Sep 2015, at 14:37, Endre Varga <endre.va...@typesafe.com >> <mailto:endre.va...@typesafe.com>> wrote: >> >> Hi Ashesh, >> >> On Wed, Sep 9, 2015 at 2:25 PM, Ashesh Ambasta <ashesh.amba...@gmail.com >> <mailto:ashesh.amba...@gmail.com>> wrote: >> Thank you for your time Endre. >> >> Well, in my opinion, that is something that needs to be documented. Because >> in my answering actor, I was using `sender()` to reply back. In this case, >> the use of the word `sender` implies that some reference to the actual actor >> that sent the message is maintained, whereas, it isn’t. >> >> It is maintained, why do you concluded it isn't? Can you demonstrate with a >> failing test case where sender() does not work? >> >> The problem with a load balancer is that it reroutes TCP connections, so an >> unsuspecting actor system thinks it connects to a certains system A while it >> ends up being connected to B. Then it sends out messages that it thinks >> should go to A, and then B rightly refuses them since those messages are not >> destined for B, but A. >> >> -Endre >> >> >> Best, >> >> Ashesh Ambasta >> www.asheshambasta.com <http://www.asheshambasta.com/> >>> On 09 Sep 2015, at 14:19, Akka Team <akka.offic...@gmail.com >>> <mailto:akka.offic...@gmail.com>> wrote: >>> >>> Hi Ashesh, >>> >>> You cannot use Akka Remoting with a load balancer. Any message send targets >>> a specific actor on a specific system (this is what an ActorRef is), you >>> cannot just take them and reroute them to unsuspecting systems. >>> >>> You can either use Akka Routers to implement your balancing (no need for >>> external load balancer), or you must use another technology to connect your >>> containers (like HTTP; for example Akka Http or Spray). >>> >>> -Endre >>> >>> On Tue, Sep 8, 2015 at 7:04 PM, Ashesh Ambasta <ashesh.amba...@gmail.com >>> <mailto:ashesh.amba...@gmail.com>> wrote: >>> Hi guys, >>> >>> We're a young startup and we decided to stick with Akka for our production >>> deployments. But we recently ran into a minefield of problems >>> <http://stackoverflow.com/questions/32461282/akka-ask-through-a-load-balancer> >>> trying to set up our Akka applications on our new Mesosphere cluster where >>> we use Marathon to deploy and run applications inside Docker containers. >>> >>> I've really run out of options at this time and this is my remoting >>> configuration: >>> >>> # Remoting configuration >>> app { >>> host = ${?APP_HOST} >>> akka { >>> port = 11112 >>> } >>> } >>> akka { >>> loglevel = DEBUG >>> jvm-exit-on-fatal-error = false >>> log-dead-letters = 1 >>> actor { >>> provider = "akka.remote.RemoteActorRefProvider" >>> } >>> remote { >>> enabled-transports = ["akka.remote.netty.tcp"] >>> netty.tcp { >>> hostname = "" >>> port = ${?app.akka.port} >>> >>> >>> bind-hostname = ${?app.host} >>> bind-port = ${?app.akka.port} >>> } >>> } >>> } >>> >>> >>> When other remote actors `ask` an actor remotely, this is what I see in my >>> logs: >>> [DEBUG] [09/08/2015 16:54:22.909] >>> [application-akka.remote.default-remote-dispatcher-8] [Remoting] >>> Associated[akka.tcp://application@10.0.2.23:11112 >>> <http://application@10.0.2.23:11112/>] <- >>> [akka.tcp://application@10.0.2.23:11120 >>> <http://application@10.0.2.23:11120/>] >>> [ERROR] [09/08/2015 16:54:22.925] >>> [application-akka.remote.default-remote-dispatcher-7][akka.tcp://application@10.0.2.23:11112/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2Fapplication%4010.0.2.23%3A11120-1/endpointWriter >>> >>> <http://application@10.0.2.23:11112/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2Fapplication%4010.0.2.23%3A11120-1/endpointWriter>] >>> dropping message [class akka.actor.ActorSelectionMessage] for non-local >>> recipient >>> [Actor[akka.tcp://application@centralapp-core.marathon.mesos:11112/]] >>> arriving at [akka.tcp://application@centralapp-core.marathon.mesos:11112 >>> <>] inbound addresses are [akka.tcp://application@10.0.2.23:11112 >>> <http://application@10.0.2.23:11112/>] >>> >>> What would be the best way to handle this? >>> >>> I've been trying my best to ask this question on Stackoverflow/IRC, but >>> I've had no replies. >>> >>> I'll appreciate any help. >>> >>> -- >>> >>>>>>>>>> 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>. >>> >>> >>> >>> -- >>> Akka Team >>> Typesafe - Reactive apps on the JVM >>> Blog: letitcrash.com <http://letitcrash.com/> >>> Twitter: @akkateam >>> >>> -- >>> >>>>>>>>>> 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 a topic in the >>> Google Groups "Akka User List" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/akka-user/Myn-Pug4Wbg/unsubscribe >>> <https://groups.google.com/d/topic/akka-user/Myn-Pug4Wbg/unsubscribe>. >>> To unsubscribe from this group and all its topics, 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/ <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/ <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 a topic in the >> Google Groups "Akka User List" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/akka-user/Myn-Pug4Wbg/unsubscribe >> <https://groups.google.com/d/topic/akka-user/Myn-Pug4Wbg/unsubscribe>. >> To unsubscribe from this group and all its topics, 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/ <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>. > > > > -- > Akka Team > Typesafe - Reactive apps on the JVM > Blog: letitcrash.com <http://letitcrash.com/> > Twitter: @akkateam > > -- > >>>>>>>>>> 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 a topic in the Google > Groups "Akka User List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/akka-user/Myn-Pug4Wbg/unsubscribe > <https://groups.google.com/d/topic/akka-user/Myn-Pug4Wbg/unsubscribe>. > To unsubscribe from this group and all its topics, 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.
