Hi Reto

You're right, replyTo won't make sense with ask unless the client is an
actor.

Differentiating on the type of message should work.

Cheers
Brian

On 9 August 2017 at 18:16, Reto Hablützel <rethab...@gmail.com> wrote:

> Hi Brian,
>
> thanks a lot for your response.
>
> What would the setup look like to work nicely with ask? I believe I would
> need the flag, which is what I wanted to avoid:
>
> Approach 1: *target ? Event(responseWanted = true)*  --> this would work,
> the processing actor could determine the sender and just reply. however I
> wanted to avoid having this flag.
> Approach 2: *target ? Event(replyTo = Some(???))*  --> this wouldn't
> work, because I cannot set the replyTo to the actor that is being created
> by ask internally.
>
> Or do I miss some feature of ask?
>
> Thinking about this again, the solution that would probably work more
> cleanly would be to have two distinct message types based on whether the
> user wants a response or not. Then I could still use tell and ask. The
> processing actor would determine based on the type of the message whether a
> response is desired.
>
> Thanks again.
>
>  - Reto
>
> On Wednesday, August 9, 2017 at 3:12:02 PM UTC+2, Brian Smith wrote:
>>
>> Hi Reto
>>
>> Not an expert but I'm not sure about the motivation here.
>>
>> What's wrong with the client deciding to use ask or tell based on whether
>> it wants a response or not (and communicating that preference to the actor
>> using the replyTo pattern you've identified)?
>>
>> What do you gain by making the choice between ask and tell transparent to
>> the client when ultimately it has the same constraints i.e. it either needs
>> to handle a response or not, and it needs to cope with not getting expected
>> responses?
>>
>> I think your instinct that you're re-implementing things might be right
>> but I may have missed something!
>>
>> Cheers
>> Brian
>>
>> On 9 August 2017 at 13:45, Reto Hablützel <reth...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have a use-case where the sender of an event shall be able to specify
>>> whether the event shall be processed in the background or an answer is
>>> expected. I wanted to express these semantics by specifying a 'replyTo:
>>> Option[ActorRef]' in the message rather than adding a flag to the message.
>>> The constraint here is that it shall work from outside the actor system as
>>> well (ie. I would need something like the ask pattern, which basically
>>> returns a future, if the event isn't sent from within an actor).
>>>
>>> I thought about these approaches, none of which seemed quite right:
>>>
>>> - Send the event with the ask pattern: This would mean I don't have a
>>> replyTo in the message, but a flag (eg. 'responseWanted'). If the flag is
>>> set to true, the processing actor would respond -- otherwise not. The
>>> problem here is that the ask pattern always expects a response within the
>>> specified timeout or throws an exception if no response is received. Also,
>>> I'd rather have an explicit replyTo attribute in the event instead of the
>>> flag.
>>>
>>> - Send the event with tell: This would mean the sender needs to be an
>>> actor as well or somehow else obtain an ActorRef to be sent along for the
>>> response. This would mean I'd have to create an ActorRef on the fly to
>>> handle the response.
>>>
>>> Eventually I ended up implementing a bit of boilerplate code that
>>> combines the two approaches (heavily inspired by the ask pattern's impl):
>>> If the sender is not interested in a response, it can just fire the event
>>> with a regular tell and set the replyTo to None. If the sender wants a
>>> response, however, it would invoke a function with this signature: *def
>>> askOpt(msgFactory: ActorRef => Any, target: ActorRef): Future[Any]*
>>> This creates an actor on the fly, creates the event with the newly created
>>> actor's ref and then sends that to the target from inside the new actor. It
>>> then races against a scheduled task, just like the ask pattern.
>>>
>>>
>>> So my questions are:
>>> - Is this a good approach? I feel like I am re-implementing lots of
>>> things that already exist in the ask pattern, however all of that is
>>> inacessible from the outside
>>> - Specifying the replyTo in the message will become much more prominent
>>> with akka-typed (as far as I understand). How would ask work in that
>>> scenario? (seems somewhat similar)
>>>
>>> Thanks a lot!
>>>
>>> - Reto
>>>
>>>
>>>
>>> Boilerplate Code:
>>>
>>>   def ask(msgFactory: ActorRef => Any, target: ActorRef)(implicit
>>> system: ActorSystem, timeout: Timeout): Future[Any] = {
>>>
>>>     val result = Promise[Any]()
>>>
>>>     val actor = system.actorOf(PromiseActor.props(result, msgFactory,
>>> target))
>>>
>>>     import system.dispatcher
>>>     val f = system.scheduler.scheduleOnce(timeout.duration) {
>>>       result tryComplete Failure(new AskTimeoutException(s"Ask timed out
>>> on [$target] after [${timeout.duration.toMillis} ms]"))
>>>     }
>>>
>>>     result.future onComplete { _ =>
>>>       try actor ! PoisonPill finally f.cancel()
>>>     }
>>>
>>>     result.future
>>>   }
>>>
>>>   private class PromiseActor(p: Promise[Any], evtFactory: ActorRef =>
>>> Any, target: ActorRef) extends Actor {
>>>
>>>     override def preStart: Unit = {
>>>       target ! evtFactory(self)
>>>     }
>>>
>>>     override def receive: Receive = {
>>>       case res: Any =>
>>>         p.success(res)
>>>         context.stop(self)
>>>     }
>>>
>>>   }
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> 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 akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> 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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to