You are right. I will continue to dig a bit more into those issues. On Thursday, September 25, 2014 3:44:34 PM UTC+2, Björn Antonsson wrote: > > Hi Olivier, > > On 24 September 2014 at 18:02:12, Olivier Corradi (olivier...@gmail.com > <javascript:>) wrote: > > Hi Björn, > > Thanks for replying. Here are some responses > > *1) Are there many different routes that the messages can take to get to > the actor?* > Messages originate from various APIs that might involve delays (hence the > ordering problem). Once they reach the akka cluster, they are directly > routed to the persistence actor, but there's no controlling them before > then. > > *2) How much lag is there in the system? I mean how long after message t1 > can you get a t2 that is before t1?* > The lag is very variable, but it could be on the order of magnitude of > minutes. However there is no upper bound, so a simple aggregator won't cut > it. > > *3) How much drift are there between clocks? At which granularity can you > trust that t1 from one source is newer than t2 from another source? Or is > there a single source of truth when it comes to time?* > There is a single source of truth when it comes to time. The creation > datetime imbedded in the message (at the source) is the reference. > > *4) All messages to an actor are processed sequentially in the order that > they are received. You don't need to involve stashing, or maybe I > misunderstood you?* > If a blocking method is used, then they are processed sequentially. > However this might not be a good practice, hence the idea to stash incoming > messages while doing async calls, in order to guarantee the sequential > processing of messages. > > > If you send messages M1, M2 and M3 from actor A to actor B in that order, > then actor B will process them sequentially in the order M1, M2, M3. If you > while processing a message need to wait for a reply, then you could use > stashing, but that can easily lead to overflows of your inbox (or stash) > for that matter, and if your actor crash, then everything in the stash is > lost. > > Right now I'm looking at a solution that looks like this: > > - Persist messages as they arrive, and process them using a blocking call, > updating the state accordingly > - If a message that has been created before the last state update arrives, > delete all snapshots that are older than the message creation data, and > throw an exception to restart the actor with immediate recovery (the > message queue has been persisted so we are fine). > - Use a journal implementation overriding the asyncReplayMessages method > to replay messages in message creation order, and not in persisted order > (very hacky: we should be able to do better). Because invalid snapshots > have been deleted, we are replaying up to a consistent state. > > This is not a very good solution as ideally we shouldn't be touching the > journaling system, although it actually works on my test bench. Maybe I'm > just pushing persistence to it's boundaries :) > > Let me know what you think. > > > This sounds like an abuse of the persistence module and the journal api. > Your requirements about replaying the commands in a different order than > received and persisted doesn't fit well with the model. You can still use > the snapshot feature to save internal actor state, but I would simply > persist the commands in a different store where you can sort them by time > easily. > > B/ > > Olivier > > > On Tuesday, September 23, 2014 9:25:25 AM UTC+2, Björn Antonsson wrote: >> >> Hi, >> >> So to better understand your problem, I have a couple of questions about >> your requirements. >> >> 1) Are there many different routes that the messages can take to get to >> the actor? >> >> 2) How much lag is there in the system? I mean how long after message t1 >> can you get a t2 that is before t1? >> >> 3) How much drift are there between clocks? At which granularity can you >> trust that t1 from one source is newer than t2 from another source? Or is >> there a single source of truth when it comes to time? >> >> 4) All messages to an actor are processed sequentially in the order that >> they are received. You don't need to involve stashing, or maybe I >> misunderstood you? >> >> B/ >> >> On 21 September 2014 at 17:29:53, Olivier Corradi (olivier...@gmail.com) >> wrote: >> >> Hello, >> >> Consider the following requirements: >> >> - Messages need to be processed sequentially, because they alter the >> actor's state >> - Message processing order is determined by an internal attribute of the >> message (in this case a specific datetime) >> >> What are best practices for such a design? >> >> I've looked into Stash and Priorities with Akka Persistence Actors: >> - Stashing messages guarantees sequential processing >> - Persistence enables replay of messages in case a "late" message >> triggers invalidates the state (because it needs to be processed before >> other messages) >> - Priority mailbox minimises the number of replays by ordering stashed >> messages >> >> Thank you in advance >> -- >> >>>>>>>>>> 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. >> >> >> -- >> Björn Antonsson >> Typesafe <http://typesafe.com/> – Reactive Apps on the JVM >> twitter: @bantonsson <http://twitter.com/#!/bantonsson> >> >> -- > >>>>>>>>>> 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 <javascript:>. > To post to this group, send email to akka...@googlegroups.com > <javascript:>. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > > > -- > Björn Antonsson > Typesafe <http://typesafe.com/> – Reactive Apps on the JVM > twitter: @bantonsson <http://twitter.com/#!/bantonsson> > >
-- >>>>>>>>>> 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.
