You made a fair point, doctor. What do you think regarding the exchange example I came up with in my previous post? Shall I switch to use Processor from EventsourcedProcessor and simple use 'deleteMessage' for all commands whose precondition check fails (so to ignore them for quicker recovery)?
On Thursday, February 20, 2014 4:40:05 PM UTC+8, rkuhn wrote: > > > 20 feb 2014 kl. 09:07 skrev dong <don...@gmail.com <javascript:>>: > > And here is another question regarding channel and command sourcing > Processor. > > My understanding is this, when a event is received by Processor: > 1) persist the event > 2) handle the event > 3) call event.confirm() > > In case something wrong in step 2, channel will attempt to redeliver the > same message to Processor, then step 1 will happen again, this means the > same message is journaled twice. Based on current implementation, it's not > a problem as journaling twice actually end up with the same message. But > why not merge 1 and 3 so once a channel-delivered-persistent event is > received and journaled by Processor, the confirm() is done automatically? > > > The confirmation is about the recipient’s state, i.e. whether it has > handled the command or not. This fully closes the business-level > acknowledgement loop. Other products market “guaranteed delivery” as “we > will give the recipient a chance to process the message, subject to the > fine print” (where most people don’t read the fine print, as usual ;-)), > but I don’t think that makes much sense because your business processes > only care about whether the business function was executed successfully or > not—the intermediate steps of trying to send the message, having received > the message, having begun the processing, etc. are not that useful in that > their meaning is quite fuzzy. > > Now you could argue that having persisted the message at the recipient end > is good enough because it will eventually process it in any case, but that > is not true since it relies on that recovery is eventually executed often > enough that the operation succeeds. > > The goal of Akka Persistence is to enable at-least-once delivery > semantics, meaning that sending a message will make sure that it will be > processed by the recipient (well, there is fine print obviously in the > sense that the recipient must eventually become available, not terminate, > or some such). > > Regards, > > Roland > > Of course, this requires we to distinguishi a Persistent message and a > channel-delivered-persistent message. > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://akka.io/faq/ > >>>>>>>>>> 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/groups/opt_out. > > > > > *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://akka.io/faq/ >>>>>>>>>> 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/groups/opt_out.
