Persistence of dynamic hierarchy of actors with short/medium length of life

[Robert Budźko]

Hi!

I've recently encountered puzzling challenge of serializing dynamic hierarchy of actors. In this class of use case actors usually do live very short (seconds) or eventually medium lives (minutes) and  spawn more and more actors if required (delegation), so references are rapidly exchanged in between them. As stated in documentation ActorRef is not the best model to serialize due to incarnation ID, so path needs to be persisted and lookup should be done during serialization (or alter). It doesn't feel comfortable because failures/migrations of actor are fairly random, so often lookup simply fail as well.

Thanks to couple of discussions online it has been pointed out that since short living actors stands for small but rapidly changing state it should be cheap and convenient not to event source them, but to recreate them during replaying sourced events of actor higher in hierarchy (usually grand^N parent), so problem of new incarnations of dynamically created actors disappear. I kind of like this idea, but I wonder if it is indeed valid and safe approach, because I still see problem of 3rd party calls (result of event processing by given actor), so I end up with two versions (usually achieved by currying) of functions to prevent duplication of calls to non-transactional/non-managable resources during recovery.

Have you solved similar problems in more elegant way then described above :-)?

Robert

[Konrad Malawski]

Hi Robert,

In order to get this right you'll need to pivot your thinking about serialization a bit, i.e. the problem statement of "serializing dynamic hierarchy of actors"

is not a good one to try to design for directly – actors are entities "which do stuff and have state". The hierarchy is not really a state you want to persist

it's just *the outcome of what actions were taken*. 

Let's say you have 10 tables, and tell people where they should sit, because it's arranged seating at your wedding.

If you suddenly explode, and we need to find out how everybody is supposed to be seating, I don't want to store some representation of "the seating graph",

but I'd persist the "list of seat assignments". Then I can simply re build the structure, and well, if there already is the right person on the right place,

I don't need to re-seat them there, I just notice "oh ok he/she's already there".

In other words, if your parent actor needs to have work done, it should store the intent "I will try to get this done", and then act upon this.

Creating the child actor etc... If all crash before getting completion of that job, he'd again act upon the fact of "I will try to get this done".

You mention 3rd party resources - in that case you'd have a problem anyway, there needs to be some way of either retrying requests idempotently (love this property),

or making sure that making the action is safe to do in the first place (when you're about to retry).

Hope this helps!

--
>>>>>>>>>> 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.

--

Cheers,

Konrad 'ktoso' Malawski

Akka @ Typesafe

[Robert Budźko]

Hi Konrad,

Yup, intent based approach makes it tick. I've already applied it successfully to the project. I fear intent hell now :-).

Robert

[Konrad Malawski]

Yup, intent based approach makes it tick. I've already applied it successfully to the project. 

Btw, I guess this is something other developers may bump into as well, would you be up to documenting this pattern?

Either as part of the documentation or as a blog maybe?

I fear intent hell now :-).

The only thing we should fear... is fear itself! (-:

-- Konrad

[Robert Budźko]

Sure. I'm preparing workshops for my colleagues soon, so I'll merge part about intents into it and check if my examples are clear for others. Then akka/akka-docs, right?

[Konrad Malawski]

Sounds great, thanks!

-- 

Cheers,

Konrad 'ktoso’ Malawski
Akka @ Typesafe

On 22 October 2015 at 13:12:17, Robert Budźko (robert.krzy...@gmail.com) wrote:

Sure. I'm preparing workshops for my colleagues soon, so I'll merge part about intents into it and check if my examples are clear for others. Then akka/akka-docs, right?