> 30 nov 2014 kl. 16:34 skrev Soumya Simanta <[email protected]>:
> 
> Roland, 
> 
> Thanks for explaining this very nicely. This is consistent with my 
> understanding. 
> 
> I try to avoid using the ask pattern (if I can) because of the timeout issue. 
> 
> So basically if you have complete control over all your messages, it better 
> to explicitly pass a unique message identifier and use that to track the 
> request-response flow. 
> Do you agree with this recommendation? 

Yes.

Regards,

Roland

> 
> Thanks again ! 
> -Soumya
> 
> 
> 
> On Sunday, November 30, 2014 10:02:17 AM UTC-5, rkuhn wrote:
> 
>> 30 nov 2014 kl. 14:53 skrev Soumya Simanta <[email protected] 
>> <javascript:>>:
>> 
>> As far as I know the following only two options: 
>> 
>> 1. Use a requestId (or context object as in Spray) that you pass along with 
>> your messages to your actors in the chain. The advantage is that you are not 
>> setting a timeout here. But you have to deal with co-relating messages 
>> yourself. 
>> 2. Use the ask pattern where you need to set a timeout but Akka will take 
>> care of getting the matching the request with the response. 
>> 
>> I was wondering if there is any other way of doing this ? 
> 
> If you consider that the real message is Envelope(payload, sender), these two 
> options collapse into one: the only way to make sense of the response is to 
> include identifying information in the request, which can either be placed in 
> the payload or the sender fields. Using “ask” does the latter by creating a 
> unique one-time recipient.
> 
> You can think of the difference also as
> the meta-information travels with the message (and needs to be understood by 
> the recipient)
> the meta-information stays with the sender (in the form of the “ask”-ActorRef 
> and possible Future transformation closures)
> 
> The second case is the only possibility if the recipient’s protocol does not 
> allow disambiguation:
> 
> case Whatever(..., x) =>
>   otherActor ? Request(...) collect {
>     case r: Response => ResponseWithContext(r, x)
>   } pipeTo self
> case ResponseWithContext(r, x) =>
>   // continue the process
> 
> The value `x` above is the identifying piece that allows the actor to keep 
> different requests separate, and if the `otherActor` cannot pass back this 
> information in its `Response` then we can remember it in the `collect` 
> closure and piece things together afterwards.
> 
> This should motivate why you should always include client-chosen identifiers 
> in the Actor protocols you design, because that makes this kind of dance 
> unnecessary (i.e. `Request` should allow passing along `x`—usually called a 
> correlation ID—and Response should just include that value as well).
> 
> Regards,
> 
> Roland
> 
>> 
>> Thanks
>> -Soumya
>> 
>> 
>> On Sunday, November 30, 2014 5:39:47 AM UTC-5, Balázs Kossovics wrote:
>> Hi Karthik,
>> 
>> Did you check out the ask pattern 
>> (http://doc.akka.io/docs/akka/snapshot/scala/actors.html#Ask__Send-And-Receive-Future
>>  
>> <http://doc.akka.io/docs/akka/snapshot/scala/actors.html#Ask__Send-And-Receive-Future>)?
>>  It may be the thing you need.
>> 
>> 
>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <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 http://groups.google.com/group/akka-user 
>> <http://groups.google.com/group/akka-user>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> 
> Dr. Roland Kuhn
> Akka Tech Lead
> Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
> twitter: @rolandkuhn
>  <http://twitter.com/#!/rolandkuhn>
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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] 
> <mailto:[email protected]>.
> To post to this group, send email to [email protected] 
> <mailto:[email protected]>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
twitter: @rolandkuhn
 <http://twitter.com/#!/rolandkuhn>

-- 
>>>>>>>>>>      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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to