Pergunta

Any known cases where TypedActor.getContext().sender() does not behave as expected?

I know that in fire-and-forget mode, it defaults to deadLetters, however I am running into something different:

// inside MainActor

IPrintingActor printingActor = create(IPrintingActor.class, PrintingActor.class);
printingActor.blockingPrintln("foo");

where create above is simply a wrapper for the usual typedActorOf call

// inside PrintingActor
@Override
public boolean blockingPrintln(String string)
{
   System.out.println(TypedActor.context().sender() + " says " + string);
   return true;
}

The output is

Actor[akka://MySystem/user/$b] says foo

however, this actor is actually the same as TypedActor.context().self().

Any reasons the sender() call would return the same as self()? Printing statements in the main actor print

Actor[akka://MySystem/user/$a]

for the MainActor and

Actor[akka://MySystem/user/$b]

for the PrintingActor. Within the PrintingActor, however, they are both printed as

Actor[akka://MySystem/user/$b]

Help greatly appreciated!

Foi útil?

Solução

The sender of the message which signified the method invocation will always be a temporary actor generated by the “ask” pattern, e.g. .../temp/$a. The reason is that it is not an actor which receives the reply but some internal entity which then returns the reply value as the method invocation return value. Hence no matter how it is implemented, you will never see the ref of the actor enclosing the method’s call site as the sender.

On a side note: I cannot reproduce your findings (i.e. that the sender was .../user/$a or similar), but you also did not specify which version of Akka you are using.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top