Normally you’d simple have an Actor do this, instead of hacking into the internals as proposed in your snippet :-) Have an actor who’d keep messages and forward to the target once it’s received it.
Having that said, we have the concept of such “FutureRef” defined and implemented in AkkaTyped, it’s not ported over to Akka classic yet AFAIR. https://github.com/akka/akka/blob/master/akka-typed/src/main/scala/akka/typed/ActorRef.scala#L69 Note that there is a akka.actor.pattern that someone contributed in Akka but that’s not what this is. I actually wonder if that one should remain or be removed hm… You can investigate that semantics and if it is you can open a ticket about porting it to classic Akka, I think we don’t have such ticket yet. I opened a related ticket, in which we should perhaps remove or disambiguate the current akka.pattern one, since it has same name but different mechanics nowadays https://github.com/akka/akka/issues/23924 Hope this helps. -- Cheers, Konrad 'ktoso <http://kto.so>' Malawski Akka <http://akka.io/> @ Lightbend <http://lightbend.com/> On November 6, 2017 at 6:30:50, Alexandr Sova ([email protected]) wrote: Hello, Akka community! Sometimes there are situations when you don't have an ActorRef instance but you know where to ask for it. It may be because actor is still haven't being created and actor creation procedure requires some long-running tasks to be completed for instance your application requires actor A that have a dependency on component B which in turn depends on resource C that may not be retrieved on application startup... or any other precondition where actor could not exist... But you have to give this ActorRef out of ActorSystem for example to Play! controller or some different service (let's call it "client D"), whatever but you don't want to show the implementation detail about actor still does not exist, you just want to pass ActorRef as a constructor parameter. What would you do? In traditional systems I'd solve it with some kind of ProxyActorRef that'd look something like that: class ProxyActorRef(provider: () => Future[ActorRef]) extends ActorRef with ScalaActorRef { private val futureRef = provider() override def path: ActorPath = ??? override def !(message: Any)(implicit sender: ActorRef): Unit = futureRef.onComplete({ case Success(ref) => ref.tell(message, sender) case _ => // do nothing }) } but with current akka implementation I just can't do it because of ProxyActorRef does not confirm to InternalActorRef and InternalActorRef is private[akka] Usually akka have a way to solve most of problems that could happen - *do anyone knows how to solve this kind of problem?* And to have separate actor in front of actor A is not a solution because actor A can be Router.fromConfig and nesting all the calls to distinct actor: - makes all effort on building configurable proxy worthless - can have a performance impact <https://doc.akka.io/docs/akka/current/scala/routing.html#how-routing-is-designed-within-akka> any way if performance could be sacrificed than simple router <https://doc.akka.io/docs/akka/current/scala/routing.html#a-simple-router> with routing logic at actor rather than at actorRef would be much better solution, but what if that is not a case and performance is significant? And also to have componentB/resourceC acquire logic separate at actor A also couldn't be an answer because that way you couldn't expect componentB as a constructor dependency so actor starts at a state when it just can't do the work which it supooses to so your actor A should become a FSM and this approach is rather overhead/overcomplicated. And to wrap expectation for ActorRef into another object which is not instanceof ActorRef (couldn't be used with akka.patterns._ for example) is also not a solution because you don't want to show your implementation detail about that dependency may not ready when "clientC" gets created. Do anyone have any idea around it? Or may be pull request to akka with such functionality can be a good thing? -- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
