I though you should also have a look at different patterns one can use to
implement waiting for something,
this has been discussed nicely in this thread: Waiting on multiple Akka
messages
<https://groups.google.com/forum/#!searchin/akka-user/multiple$20fsm$20messages/akka-user/KqePSVbaQEM/7L_cM9TNKAsJ>
.
On Thu, Jul 31, 2014 at 4:08 PM, Adam <adamho...@gmail.com> wrote:
> I was facing a similar decision a few weeks ago.
>
> For now, I've went with the actor per request approach that Martynas
> mentions.
> The actor basically looks like a series of receive methods and I use
> become to switch between them.
> Each switch is done whenever I need to wait for an asynchronous call
> (usually when accessing the database).
>
> I also tried the approach of using futures (via the ask pattern), but this
> indeed was harder to work with mainly because it was hard to troubleshoot
> based on error messages and becuase I kept having to disable or lengthen
> these timeouts while debugging.
>
> Note that I don't copy context data between become calls, I use private
> members in the Actor (the blog post also mentions this).
>
>
>
>
>
> On Monday, July 28, 2014 12:49:31 AM UTC+3, Bartłomiej Szczepanik wrote:
>>
>> Dear Hakkers,
>>
>>
>> In my current project I have experienced that ask pattern is a kind of
>> awkward solution. I really like it for its elegance and readability but
>> besides not very efficient implementation (spawning actor per each request)
>> it introduces a phenomenon which I call `timeout hell`. It is really hard
>> to introduce a consistent timeout for a user request when you use several
>> ask requests in your pipeline.
>>
>>
>>
>> I have also seen that many people discourage from using that pattern and
>> encourage to replace it with actor per request pattern. Personally I don't
>> see any difference with the ask implementation with a new actor spawned
>> each time. It would be great if someone convince me why it is different and
>> better.
>>
>>
>>
>> I'm guessing the cause of this problem is not about the usage of the ask
>> pattern itself but due to crappy, not reactive design of the system. I
>> agree that the best is not to wait or block for anything. But currently I
>> cannot use fully reactive pipeline with pushing events to GUI and so on.
>> However, I'd like to block user only on HTTP request and be fully reactive
>> in the rest of the pipeline. But still there is a problem. Let me describe
>> it on a simple example.
>>
>>
>>
>> Let's say the backend can handle ChangeColorOfItem command. In the
>> old-style application we probably would write something like (pseudocode):
>>
>> on(ChangeColorOfItem cmd) {
>>
>> item = itemRepository.getById(cmd.itemId)
>>
>> item.changeColorTo(cmd.getColor)
>>
>> itemRepository.save(item)
>>
>> }
>>
>>
>>
>> It's easy for me to translate it to akka using ask pattern. But as I
>> said, I would like to avoid it. I came up with several possible solutions:
>>
>>
>>
>> Fire and forget solution
>>
>>
>>
>> The idea is to move all but first steps to recipients of respective
>> messages. For example the repository command retrieves the requested item
>> and sends message to the retrieved item basing on the passed context. I
>> don't like the idea because of scattering of business logic and hindering
>> the reusability of components.
>>
>>
>>
>> Create an actor and split the business logic on multiple steps
>>
>>
>>
>> Something more sophisticated. Here's some sample of code:
>>
>>
>>
>> Receive = {
>>
>> match msg @ ChangeColorOfItem(itemId, color) => {
>>
>> itemRepository ! GetById(itemId, Context(sender, msg))
>>
>> }
>>
>> match RepositoryResponse(item: ActorRef, context) => {
>>
>> item ! ChangeColorTo(context.msg.color, context)
>>
>> }
>>
>> match event @ ColorChanged(itemId, color, context) => {
>>
>> itemRepository ! SaveEvent(event)
>>
>> }
>>
>> match ItemSaved(context) => {
>>
>> context.sender ! ColorSuccessfullyChanged(context.msg.id,
>> context.msg.color)
>>
>> }
>>
>> }
>>
>>
>>
>> Advantages (comparing to ask pattern):
>>
>> - The entire use case logic is still in one place (one actor)
>> - Timeouts handling moved on a higher level (e.g. REST interface
>> level) what enables easy timeout management per entire use case
>> - No problem with resource leaks when there is a timeout or heavy
>> load (no stale future objects in memory, only lightweight message)
>>
>>
>>
>> Disadvantages:
>>
>> - Need to pass context explicitly all the time
>> - Logic is harder to read due to steps introduction (a little similar
>> to use of callbacks)
>> - Exclusive processing of steps that in fact don't need that
>>
>>
>>
>> Different ideas
>>
>>
>>
>> I was thinking about leveraging Futures for similar idea as above. I
>> wanted to pass some kind of callback with the message and it's context to
>> the next recipient. That allows me to keep code in one place (unfortunately
>> in callbacks but still). However I think it is impossible to send a lambda
>> in a message to the actor. Is that any workaround? If so, would you find
>> this approach useful?
>>
>>
>>
>> Generally I would prefer to use a solution that keeps the idea of
>> "application/use case service" which orchestrates the fine-grained classes
>> and encapsulates use cases in the code in exactly one place. If you
>> think it's impossible in reactive approach, please explain that and give
>> some alternatives. I'd be very grateful for that.
>>
>>
>> Best,
>>
>> Bartłomiej
>>
>>
>>
>>
>
>
>
>
>
> --
> >>>>>>>>>> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe
<http://typesafe.com>
--
>>>>>>>>>> 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
