Tackling the ask pattern and `timeout hell`
Bartłomiej Szczepanik
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
Martynas Mickevičius
--
>>>>>>>>>> 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+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Adam
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).
Konrad Malawski
--
>>>>>>>>>> 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+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
