Wow! Konrad, it's such an honor for me that you paid attention to my question.
As I mentioned at first post - if a target is a router.fromConfig then > Have an actor who’d keep messages and forward to the target once it’s received it. would have a performance impact because this way message should: 1. be placed to actor mailbox 2. wait till actor would fetch it from there 3. be sent to target and this all is one message at a time. This way there is no sense to make a router.fromConfig and delegate routing logic to ActorRef but a "simple router" solution could do the job and performance impact would be the same or even a bit lower which is not acceptable at cases with high message rates. At "high message rates" cases router.fromConfig with routing logic delegated to ActorRef could be a significant performance gain *if every worker behind the router have it's own mailbox and not share same mailbox with router*. Or am I don't understand something and should be pointed to RTFM? I'd definitely study the concept of FutureRef and'll open a ticket about porting in the near future Once again thanks a lot that you paid attention to my question and pointed me that ways. On Monday, November 6, 2017 at 10:26:26 AM UTC+2, Konrad Malawski wrote: > > 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] > <javascript:>) 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] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > 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.
