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.) 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+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.
