Performing actor lookup with Akka actorFor
I have the following Akka actor:
public class MyActor extends AbstractActor {
protected Logger log = LoggerFactory.getLogger(this.getClass());
@Override
public Receive createReceive() {
return receiveBuilder()
.matchAny(message -> {
String myFullName = self().path().toString();
String myName = self().path().name();
ActorRef reincarnatedMe = context().actorFor(self().path().name());
String reincarnatedFullName = reincarnatedMe.path().toString();
String reincarnatedName = reincarnatedMe.path().name();
log.info("myFullName: {}", myFullName);
log.info("myName: {}", myName);
log.info("reincarnatedFullName: {}", reincarnatedFullName);
log.info("reincarnatedName: {}", reincarnatedName);
}).build();
}
}
At runtime it produces this output:
05:43:14.617 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - myFullName: akka://MySystem/user/MyActor
05:43:14.623 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - myName: MyActor
05:43:14.623 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - reincarnatedFullName: akka://MySystem/user/MyActor/MyActor
05:43:14.623 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - reincarnatedName: MyActor
My understanding was that context().actorFor(...)
doesn't create a new actor, rather it finds an existing actor that matches the path/string you provide and returns a reference to it.
However, it appears that in my code above, self()
becomes the parent of reincarnatedMe
as evidenced by myFullName
simply being "MySystem/user/MyActor
" whereas reincarnatedFullName
is "MySystem/user/MyActor/MyActor
"...
Am I reading this right? If so, how can I invoke context().actorFor(...)
(or any other method for that matter) such that myFullName
becomes the same as reincarnatedFullName
(so that self()
and reincarnatedMe
reference the same actor? And if I'm not reading this right, why is myFullName
different than reincarnatedFullName
?
Update:
public class AnotherActor extends AbstractActor { ... }
// Inside MyActor#createReceive:
ActorSelection anotherActorSel = context().actorSelection("AnotherActor");
anotherActorSel.tell(new SomeMessage(), self());
java-8 akka
add a comment |
I have the following Akka actor:
public class MyActor extends AbstractActor {
protected Logger log = LoggerFactory.getLogger(this.getClass());
@Override
public Receive createReceive() {
return receiveBuilder()
.matchAny(message -> {
String myFullName = self().path().toString();
String myName = self().path().name();
ActorRef reincarnatedMe = context().actorFor(self().path().name());
String reincarnatedFullName = reincarnatedMe.path().toString();
String reincarnatedName = reincarnatedMe.path().name();
log.info("myFullName: {}", myFullName);
log.info("myName: {}", myName);
log.info("reincarnatedFullName: {}", reincarnatedFullName);
log.info("reincarnatedName: {}", reincarnatedName);
}).build();
}
}
At runtime it produces this output:
05:43:14.617 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - myFullName: akka://MySystem/user/MyActor
05:43:14.623 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - myName: MyActor
05:43:14.623 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - reincarnatedFullName: akka://MySystem/user/MyActor/MyActor
05:43:14.623 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - reincarnatedName: MyActor
My understanding was that context().actorFor(...)
doesn't create a new actor, rather it finds an existing actor that matches the path/string you provide and returns a reference to it.
However, it appears that in my code above, self()
becomes the parent of reincarnatedMe
as evidenced by myFullName
simply being "MySystem/user/MyActor
" whereas reincarnatedFullName
is "MySystem/user/MyActor/MyActor
"...
Am I reading this right? If so, how can I invoke context().actorFor(...)
(or any other method for that matter) such that myFullName
becomes the same as reincarnatedFullName
(so that self()
and reincarnatedMe
reference the same actor? And if I'm not reading this right, why is myFullName
different than reincarnatedFullName
?
Update:
public class AnotherActor extends AbstractActor { ... }
// Inside MyActor#createReceive:
ActorSelection anotherActorSel = context().actorSelection("AnotherActor");
anotherActorSel.tell(new SomeMessage(), self());
java-8 akka
add a comment |
I have the following Akka actor:
public class MyActor extends AbstractActor {
protected Logger log = LoggerFactory.getLogger(this.getClass());
@Override
public Receive createReceive() {
return receiveBuilder()
.matchAny(message -> {
String myFullName = self().path().toString();
String myName = self().path().name();
ActorRef reincarnatedMe = context().actorFor(self().path().name());
String reincarnatedFullName = reincarnatedMe.path().toString();
String reincarnatedName = reincarnatedMe.path().name();
log.info("myFullName: {}", myFullName);
log.info("myName: {}", myName);
log.info("reincarnatedFullName: {}", reincarnatedFullName);
log.info("reincarnatedName: {}", reincarnatedName);
}).build();
}
}
At runtime it produces this output:
05:43:14.617 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - myFullName: akka://MySystem/user/MyActor
05:43:14.623 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - myName: MyActor
05:43:14.623 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - reincarnatedFullName: akka://MySystem/user/MyActor/MyActor
05:43:14.623 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - reincarnatedName: MyActor
My understanding was that context().actorFor(...)
doesn't create a new actor, rather it finds an existing actor that matches the path/string you provide and returns a reference to it.
However, it appears that in my code above, self()
becomes the parent of reincarnatedMe
as evidenced by myFullName
simply being "MySystem/user/MyActor
" whereas reincarnatedFullName
is "MySystem/user/MyActor/MyActor
"...
Am I reading this right? If so, how can I invoke context().actorFor(...)
(or any other method for that matter) such that myFullName
becomes the same as reincarnatedFullName
(so that self()
and reincarnatedMe
reference the same actor? And if I'm not reading this right, why is myFullName
different than reincarnatedFullName
?
Update:
public class AnotherActor extends AbstractActor { ... }
// Inside MyActor#createReceive:
ActorSelection anotherActorSel = context().actorSelection("AnotherActor");
anotherActorSel.tell(new SomeMessage(), self());
java-8 akka
I have the following Akka actor:
public class MyActor extends AbstractActor {
protected Logger log = LoggerFactory.getLogger(this.getClass());
@Override
public Receive createReceive() {
return receiveBuilder()
.matchAny(message -> {
String myFullName = self().path().toString();
String myName = self().path().name();
ActorRef reincarnatedMe = context().actorFor(self().path().name());
String reincarnatedFullName = reincarnatedMe.path().toString();
String reincarnatedName = reincarnatedMe.path().name();
log.info("myFullName: {}", myFullName);
log.info("myName: {}", myName);
log.info("reincarnatedFullName: {}", reincarnatedFullName);
log.info("reincarnatedName: {}", reincarnatedName);
}).build();
}
}
At runtime it produces this output:
05:43:14.617 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - myFullName: akka://MySystem/user/MyActor
05:43:14.623 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - myName: MyActor
05:43:14.623 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - reincarnatedFullName: akka://MySystem/user/MyActor/MyActor
05:43:14.623 [MySystem-akka.actor.default-dispatcher-4] INFO myapp.actors.MyActor - reincarnatedName: MyActor
My understanding was that context().actorFor(...)
doesn't create a new actor, rather it finds an existing actor that matches the path/string you provide and returns a reference to it.
However, it appears that in my code above, self()
becomes the parent of reincarnatedMe
as evidenced by myFullName
simply being "MySystem/user/MyActor
" whereas reincarnatedFullName
is "MySystem/user/MyActor/MyActor
"...
Am I reading this right? If so, how can I invoke context().actorFor(...)
(or any other method for that matter) such that myFullName
becomes the same as reincarnatedFullName
(so that self()
and reincarnatedMe
reference the same actor? And if I'm not reading this right, why is myFullName
different than reincarnatedFullName
?
Update:
public class AnotherActor extends AbstractActor { ... }
// Inside MyActor#createReceive:
ActorSelection anotherActorSel = context().actorSelection("AnotherActor");
anotherActorSel.tell(new SomeMessage(), self());
java-8 akka
java-8 akka
edited Nov 20 '18 at 17:22
hotmeatballsoup
asked Nov 20 '18 at 11:01
hotmeatballsouphotmeatballsoup
107311
107311
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
First, ActorContext.actorFor(String)
is deprecated in favor of ActorContext.actorSelection(String)
. This method returns an ActorSelection, but you can still send a message to an ActorSelection (such as an Identify, which response with an ActorIdentity message automatically).
The documentation for the actorFor
method says that, "Absolute URIs like akka://appname/user/actorA are looked up as described for look-ups by actorOf(ActorPath)." I can't find documentation on an actorOf(ActorPath)
method, but the other actorOf
methods state they create new actors, so I suspect this does the same. The behavior you've found is likely the reason for the deprecation -- or because it was deprecated and the methods used for something else.
Thanks @Rob Crawford (+1) please see my update above. Regarding the use ofactorSelection(...)
, any chance you could confirm two things: (1) that I can send any message/object to anActorSelection
instance, not just baked-in ones such asIdentify
that ship with Akka, and much more importantly, (2) that the returnedActorSelection
finds and reuses (does not create!) an existing actor based on the provided selection path? Thanks again so much!
– hotmeatballsoup
Nov 20 '18 at 17:24
2
The tell() method for ActorSelection takes an Object, so any message can be sent, and I know from my own use of ActorSelection that it reuses an existing actor, if there is one. If there is no actor matching the ActorSelection, the messages go to the dead letter box.
– Rob Crawford
Nov 20 '18 at 17:26
You rock! Thanks Rob!
– hotmeatballsoup
Nov 20 '18 at 17:44
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53391554%2fperforming-actor-lookup-with-akka-actorfor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
First, ActorContext.actorFor(String)
is deprecated in favor of ActorContext.actorSelection(String)
. This method returns an ActorSelection, but you can still send a message to an ActorSelection (such as an Identify, which response with an ActorIdentity message automatically).
The documentation for the actorFor
method says that, "Absolute URIs like akka://appname/user/actorA are looked up as described for look-ups by actorOf(ActorPath)." I can't find documentation on an actorOf(ActorPath)
method, but the other actorOf
methods state they create new actors, so I suspect this does the same. The behavior you've found is likely the reason for the deprecation -- or because it was deprecated and the methods used for something else.
Thanks @Rob Crawford (+1) please see my update above. Regarding the use ofactorSelection(...)
, any chance you could confirm two things: (1) that I can send any message/object to anActorSelection
instance, not just baked-in ones such asIdentify
that ship with Akka, and much more importantly, (2) that the returnedActorSelection
finds and reuses (does not create!) an existing actor based on the provided selection path? Thanks again so much!
– hotmeatballsoup
Nov 20 '18 at 17:24
2
The tell() method for ActorSelection takes an Object, so any message can be sent, and I know from my own use of ActorSelection that it reuses an existing actor, if there is one. If there is no actor matching the ActorSelection, the messages go to the dead letter box.
– Rob Crawford
Nov 20 '18 at 17:26
You rock! Thanks Rob!
– hotmeatballsoup
Nov 20 '18 at 17:44
add a comment |
First, ActorContext.actorFor(String)
is deprecated in favor of ActorContext.actorSelection(String)
. This method returns an ActorSelection, but you can still send a message to an ActorSelection (such as an Identify, which response with an ActorIdentity message automatically).
The documentation for the actorFor
method says that, "Absolute URIs like akka://appname/user/actorA are looked up as described for look-ups by actorOf(ActorPath)." I can't find documentation on an actorOf(ActorPath)
method, but the other actorOf
methods state they create new actors, so I suspect this does the same. The behavior you've found is likely the reason for the deprecation -- or because it was deprecated and the methods used for something else.
Thanks @Rob Crawford (+1) please see my update above. Regarding the use ofactorSelection(...)
, any chance you could confirm two things: (1) that I can send any message/object to anActorSelection
instance, not just baked-in ones such asIdentify
that ship with Akka, and much more importantly, (2) that the returnedActorSelection
finds and reuses (does not create!) an existing actor based on the provided selection path? Thanks again so much!
– hotmeatballsoup
Nov 20 '18 at 17:24
2
The tell() method for ActorSelection takes an Object, so any message can be sent, and I know from my own use of ActorSelection that it reuses an existing actor, if there is one. If there is no actor matching the ActorSelection, the messages go to the dead letter box.
– Rob Crawford
Nov 20 '18 at 17:26
You rock! Thanks Rob!
– hotmeatballsoup
Nov 20 '18 at 17:44
add a comment |
First, ActorContext.actorFor(String)
is deprecated in favor of ActorContext.actorSelection(String)
. This method returns an ActorSelection, but you can still send a message to an ActorSelection (such as an Identify, which response with an ActorIdentity message automatically).
The documentation for the actorFor
method says that, "Absolute URIs like akka://appname/user/actorA are looked up as described for look-ups by actorOf(ActorPath)." I can't find documentation on an actorOf(ActorPath)
method, but the other actorOf
methods state they create new actors, so I suspect this does the same. The behavior you've found is likely the reason for the deprecation -- or because it was deprecated and the methods used for something else.
First, ActorContext.actorFor(String)
is deprecated in favor of ActorContext.actorSelection(String)
. This method returns an ActorSelection, but you can still send a message to an ActorSelection (such as an Identify, which response with an ActorIdentity message automatically).
The documentation for the actorFor
method says that, "Absolute URIs like akka://appname/user/actorA are looked up as described for look-ups by actorOf(ActorPath)." I can't find documentation on an actorOf(ActorPath)
method, but the other actorOf
methods state they create new actors, so I suspect this does the same. The behavior you've found is likely the reason for the deprecation -- or because it was deprecated and the methods used for something else.
answered Nov 20 '18 at 17:05
Rob CrawfordRob Crawford
25749
25749
Thanks @Rob Crawford (+1) please see my update above. Regarding the use ofactorSelection(...)
, any chance you could confirm two things: (1) that I can send any message/object to anActorSelection
instance, not just baked-in ones such asIdentify
that ship with Akka, and much more importantly, (2) that the returnedActorSelection
finds and reuses (does not create!) an existing actor based on the provided selection path? Thanks again so much!
– hotmeatballsoup
Nov 20 '18 at 17:24
2
The tell() method for ActorSelection takes an Object, so any message can be sent, and I know from my own use of ActorSelection that it reuses an existing actor, if there is one. If there is no actor matching the ActorSelection, the messages go to the dead letter box.
– Rob Crawford
Nov 20 '18 at 17:26
You rock! Thanks Rob!
– hotmeatballsoup
Nov 20 '18 at 17:44
add a comment |
Thanks @Rob Crawford (+1) please see my update above. Regarding the use ofactorSelection(...)
, any chance you could confirm two things: (1) that I can send any message/object to anActorSelection
instance, not just baked-in ones such asIdentify
that ship with Akka, and much more importantly, (2) that the returnedActorSelection
finds and reuses (does not create!) an existing actor based on the provided selection path? Thanks again so much!
– hotmeatballsoup
Nov 20 '18 at 17:24
2
The tell() method for ActorSelection takes an Object, so any message can be sent, and I know from my own use of ActorSelection that it reuses an existing actor, if there is one. If there is no actor matching the ActorSelection, the messages go to the dead letter box.
– Rob Crawford
Nov 20 '18 at 17:26
You rock! Thanks Rob!
– hotmeatballsoup
Nov 20 '18 at 17:44
Thanks @Rob Crawford (+1) please see my update above. Regarding the use of
actorSelection(...)
, any chance you could confirm two things: (1) that I can send any message/object to an ActorSelection
instance, not just baked-in ones such as Identify
that ship with Akka, and much more importantly, (2) that the returned ActorSelection
finds and reuses (does not create!) an existing actor based on the provided selection path? Thanks again so much!– hotmeatballsoup
Nov 20 '18 at 17:24
Thanks @Rob Crawford (+1) please see my update above. Regarding the use of
actorSelection(...)
, any chance you could confirm two things: (1) that I can send any message/object to an ActorSelection
instance, not just baked-in ones such as Identify
that ship with Akka, and much more importantly, (2) that the returned ActorSelection
finds and reuses (does not create!) an existing actor based on the provided selection path? Thanks again so much!– hotmeatballsoup
Nov 20 '18 at 17:24
2
2
The tell() method for ActorSelection takes an Object, so any message can be sent, and I know from my own use of ActorSelection that it reuses an existing actor, if there is one. If there is no actor matching the ActorSelection, the messages go to the dead letter box.
– Rob Crawford
Nov 20 '18 at 17:26
The tell() method for ActorSelection takes an Object, so any message can be sent, and I know from my own use of ActorSelection that it reuses an existing actor, if there is one. If there is no actor matching the ActorSelection, the messages go to the dead letter box.
– Rob Crawford
Nov 20 '18 at 17:26
You rock! Thanks Rob!
– hotmeatballsoup
Nov 20 '18 at 17:44
You rock! Thanks Rob!
– hotmeatballsoup
Nov 20 '18 at 17:44
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53391554%2fperforming-actor-lookup-with-akka-actorfor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown