In event sourcing principles you don't perform external side effects during replay/recovery. That doesn't prevent you from doing it, if you have a good reason for it.
Sometimes it is more useful to send messages immediately after recovery, than during recovery. Later events in the recovery might change the state in such a way that you don't need to send out the messages. An anecdote, in the early implementation of the ShardCoordinator I used watch/unwatch from the recovery. That was functionally correct, but very inefficient use of remote death watch. A better solution was to only watch the remaining actors in the state after recovery. Regards, Patrik On Mon, May 26, 2014 at 7:33 AM, Roland Kuhn <[email protected]> wrote: > Hi Lawrence, > > 21 maj 2014 kl. 17:38 skrev Lawrence Wagerfield < > [email protected]>: > > Interesting, thanks for the heads-up regarding the deprecation of > Processor :) > > While we're on the topic of event-sourcing: > > Is it legal to send messages on recovery? These are side-effecting, but > will never manifest as a failure in the sender. > > If the only reason not to 'side-effect' is to avoid failure of the actor > during recovery, then I guess the answer is 'yes', we can send messages. > However, does the reasoning go further than that such that transmitting > messages during recovery is a bad idea? > > > No, sending messages is not a bad idea per se, but the recipient will have > to be able to cope with duplicates since these messages might be sent > multiple times. In general you will find that these messages should have an > identifying property like a deterministic sequence number that allows > recipients to keep track of what they have processed already. > > Regards, > > Roland > > > Thanks, > Lawrence > > > On Tuesday, May 20, 2014 7:39:53 PM UTC+1, rkuhn wrote: >> >> Hi Lawrence, >> >> this is a very good point to bring up: systematic errors in the event >> application logic will indeed just be recreated during replay, so >> persistence does not lead to resilience in this case. However, it does >> allow you to fix the implementation of your actor and rerun the log in the >> correct fashion, fixing the bug retroactively. This works a lot better for >> event-sourcing due to explicit control over the side-effects, which is why >> we are going to remove the Processor trait and enhance >> EventsourcedProcessor’s throughput (the lack of which is currently the >> reason for having Processor at all), see https://github.com/akka/ >> akka/issues/15230. >> >> Regards, >> >> Roland >> >> 14 maj 2014 kl. 22:21 skrev Lawrence Wagerfield < >> [email protected]>: >> >> Akka documentation highlights that actor state is reset on >> failure<http://doc.akka.io/docs/akka/snapshot/general/supervision.html#supervision-directives> >> in >> standard actor systems. >> >> However, an actor powered by Persistent messages will simply have these >> messages replayed and hence will rebuild the same state. >> >> Does akka-persistence therefore assume we have designed all >> processors/views to have incorruptible internal state? >> >> -- >> >>>>>>>>>> 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. >> >> >> >> >> *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. > > > > > *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. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw <http://typesafe.com/go-reactive-activator-contest> -- >>>>>>>>>> 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.
