If I understand it you question it is about: scala> RemoteSystem.remoteActor ! Start(RemoteSystem.clusterActor)
and why the singleton actor receives sender path with "wrong" system name. You are doing something that is not supported. You grab an ActorRef belonging to one ActorSystem and use that in another ActorSystem in the same JVM. Instead you should do it as if those were in two separate JVMs (i.e. not shared memory). That means that you must bootstrap with an ActorSelection to retrieve the ActorRef from the other system. Regards, Patrik On Fri, May 9, 2014 at 6:59 AM, bhudgeons <bran...@atsoft.at> wrote: > Patrik, > > Could you take a look at this gist (and the first comment)? I've > reproduced my experience with this issue. Perhaps I'm doing something > wrong. > > Thanks! > > https://gist.github.com/bhudgeons/78cc89fb6be47ff1c975 > > > > On Friday, May 2, 2014 10:07:52 AM UTC-5, bhudgeons wrote: >> >> I had the same experience as Santoash when I tried it. I will put >> together a test case ... maybe I was doing something stupid. >> >> On Friday, May 2, 2014 2:52:41 AM UTC-5, Patrik Nordwall wrote: >>> >>> >>> >>> >>> On Thu, May 1, 2014 at 9:04 PM, bhudgeons <bra...@atsoft.at> wrote: >>> >>>> Santoash, >>>> >>>> It is certainly possible, but it is confusing. I think what is >>>> probably happening is that you are passing an ActorRef in a message to the >>>> ClusterSingleton. When you create the actor in your local system (even if >>>> it is configured for remoting), you can't then send that actorref in a >>>> message to the remote cluster node actor. (Well, you can, but the remote >>>> system won't have any way to communicate with the ActorRef you sent.) >>>> >>> >>> This is not correct. You can send an ActorRef (pointing to a local >>> actor) in a message to a actor in a remote system, and from there use the >>> received ActorRef to send messages back. >>> >>> Regards, >>> Patrik >>> >>> >>>> Instead, you need for the ClusterSingleton to create an >>>> ActorSelection that references your local actor. >>>> >>>> You could do this two ways, but only one actually works. First, you >>>> could send a message to the ClusterSingleton with the hostname, port and >>>> path of your local actor, and then the ClusterSingleton could create an >>>> ActorSelection by looking up the actor remotely. Alternatively, you would >>>> think you can have the actor on your local node send a message to the >>>> ClusterSingleton, and then reply to the actor as "sender()". As I said >>>> above, if you send the ActorRef in a message to the ClusterSingleton, it >>>> won't work. But, if you reference ```sender``` from the ClusterSingleton, >>>> the ```sender``` ActorRef should contain the remote actor path, and you'll >>>> be able to send messages back. >>>> >>>> Unfortunately, that second method doesn’t work. For some reason (I’m >>>> still trying to decide whether it is a bug), when you’re inside of a >>>> cluster actor and you look at the path of a sender, and that sender is a >>>> remote actor, the cluster actor will replace the remote actor’s system name >>>> with its own system name. When it tries to send the message back, it makes >>>> it back to the host, but it “dead letters” there because there’s no system >>>> by that name. >>>> >>>> Here’s an example from my experience: I was using >>>> actor.router.Listeners, where you can listen to the gossip() of an actor by >>>> sending it a message like Listen(self). When I tried to send that message >>>> to an actor on a remote cluster, it didn't work. Like you, I saw that the >>>> path for the ActorRef of “self” didn’t contain the host/port/path info, >>>> even though that actor was created using a system configured for remoting. >>>> So, instead, I tried this: >>>> ``` >>>> case object ListenToMe >>>> >>>> // inside the actor created in the “RemoteSystem” system >>>> clusterActor ! ListenToMe >>>> ``` >>>> and then, the cluster actor looked like this: >>>> ``` >>>> class ClusterActor extends Actor with Listeners { >>>> def receive = listenerManagement orElse { >>>> case ListenToMe => { >>>> val mySender = sender() >>>> log(“Cluster actor got ListenToMe from “ + mySender.path) >>>> self ! Listen(mySender) >>>> } >>>> ... >>>> } >>>> } >>>> ``` >>>> >>>> When I did this, the log message showed that mySender.path >>>> was akka.tcp://ClusterSystem@127.0.0.1:2552/user/remoteactor. The >>>> host and port were correct, but the system name should have been >>>> RemoteSystem, not ClusterSystem. That didn’t work. >>>> >>>> This is what I ended up doing: >>>> >>>> ``` >>>> case class ListenToMe(system:String, host:String, port:Int, name:String) >>>> >>>> // inside the actor created in the “RemoteSystem” system >>>> clusterActor ! ListenToMe(“RemotingSystem”, “127.0.0.1”, 2552, >>>> “remoteactor”) >>>> ``` >>>> and then, the cluster actor looked like this: >>>> ``` >>>> class ClusterActor extends Actor with Listeners { >>>> def receive = listenerManagement orElse { >>>> case ListenToMe(system, host, port, name) => { >>>> val selection = context.actorSelection(s"akka.tcp://$system@ >>>> $host:$port/user/$name") >>>> selection ! Identify(name) >>>> } >>>> case ActorIdentity(_, Some(ref)) => { >>>> self ! akka.routing.Listen(ref) >>>> } >>>> ... >>>> } >>>> } >>>> ``` >>>> >>>> That worked. >>>> >>>> So, using “sender” in the cluster system didn’t work, but getting an >>>> ActorSelection from the full path, and then using the Identify message and >>>> ActorIdentity response did give me the right ActorRef. >>>> >>>> Note: I could have just used the ActorSelection and sent messages using >>>> it, but I wanted to use Listeners, and the Listen message requires an >>>> ActorRef. >>>> >>>> Brandon Hudgeons >>>> >>>> >>>> On Wednesday, April 30, 2014 9:58:13 AM UTC-5, Santoash Rajaram wrote: >>>>> >>>>> I have a cluster singleton that I use with ClusterSingletonProxy and >>>>> it works really well. I am trying to find out, if its possible to "reply" >>>>> to messages from ClusterSingleton. When I try to reply to messages in the >>>>> singleton, the messages always end up in the node where the singleton is >>>>> located. I was hoping it would actually send a message back to the actor >>>>> in >>>>> a remote node. when I try to print the actor's path, I don't see the >>>>> hostName in it either. Im running both nodes on the same machine (locally >>>>> using -Dakka.remote.netty.tcp.hostname=127.0.0.1). When I tried to >>>>> log the ${sender.path} from the singleton, I see something like >>>>> this: akka://myactorsystem/user/coordinator. I was expecting to see >>>>> hostName and port there as well. But I don't see that there. >>>>> >>>>> Two questions: >>>>> >>>>> 1) Should I be able to reply to messages from ClusterSingleton? >>>>> 2) If not, how can I respond to messages from the singleton? >>>>> >>>>> >>>>> Any pointers here would be greatly appreciated! Thanks! >>>>> >>>> -- >>>> >>>>>>>>>> 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. >>>> >>> >>> >>> >>> -- >>> >>> Patrik Nordwall >>> Typesafe <http://typesafe.com/> - Reactive apps on the JVM >>> Twitter: @patriknw >>> JOIN US. REGISTER TODAY! <http://www.scaladays.org/> >>> Scala <http://www.scaladays.org/> >>> Days <http://www.scaladays.org/> >>> June 16th-18th, <http://www.scaladays.org/> >>> Berlin <http://www.scaladays.org/> >>> >>> -- > >>>>>>>>>> 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 JOIN US. REGISTER TODAY! <http://www.scaladays.org/> Scala <http://www.scaladays.org/> Days <http://www.scaladays.org/> June 16th-18th, <http://www.scaladays.org/> Berlin <http://www.scaladays.org/> -- >>>>>>>>>> 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.
