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! On Sat, Oct 3, 2015 at 9:44 PM, Robert Budźko < [email protected]> wrote: > 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 > > -- > >>>>>>>>>> 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. > -- Cheers, Konrad 'ktoso' Malawski Akka <http://akka.io/> @ 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 [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.
