20 feb 2014 kl. 08:47 skrev dong <don...@gmail.com>: > Patrik, I think that's doable workaround. Just curious what Martin thinks > regarding automatically unwrap Persistent messages in EventsourcedProcessor, > or at least let application to hand Persistent messages in receiveCommand > instead of throwing errors.
One of the principles of Akka is to fail loudly when the user attempts something which is not supported: just silently doing something else is likely to lead to frustration. On the topic of command- vs event-sourcing I find it natural to use command-sourcing at the entry point to a service (where this word is to be interpreted very loosely) and event-sourcing at the exit point (i.e. where the service produces some output). We don’t support having both boundaries be the very same actor due to technical reasons—the shrink-wrapped solution would have some surprising structure compared to individual command- and event-processors—but you can surely roll your own to make it happen: just have the actor which holds the business logic be the command-sourced processor which delegates events via a command-sourced child actor back to itself, and the child represents the event source. Regards, Roland > > > On Thursday, February 20, 2014 3:32:34 PM UTC+8, Patrik Nordwall wrote: > > > > On Thu, Feb 20, 2014 at 8:03 AM, Martin Krasser <kras...@googlemail.com> > wrote: > > On 20.02.14 07:25, dong wrote: >> Martin, thank you for the quick reply. Great work on AKKA persistence, > > Thanks. > > >> we are very likely to use it in production. > > Glad to hear that. > > >> So more questions might come to you later. >> >> 1 --------- >> What do you mean " Eventsourced processors do not support command sourcing. >> "? > > Journaling messages before they are received by a processor is referred to as > "command sourcing" (see Processor). Applications directly send a Persistent > messages to a processor. You can think of a processor maintaining a > write-ahead-log. > > An EventsourcedProcessor journals event messages after having received a > command (by calling the persist() method). Applications are not allowed to > send Persistent messages directly to an EventsourcedProcessor (= Eventsourced > processors do not support command sourcing). > > I thought I explained that in detail in the event sourcing section. Please > let me know if something needs further clarification there. > > >> In my case, I have two Eventsourced processors A, and B. A will deliver an >> event to a channel with B's actorRef so B can use that event "as a command" >> to generate subsequent events, so in A's receiveRecover method, i'm doing >> this: >> >> channel forward Deliver(Persistent(some_command_to_b), b_actor_ref) >> >> In B's receiveCommand I have: >> >> case msg @ ConfirmablePersistent(e: SomeCommandToB, _, _) => >> >> Do you think this is problematic? > > Yes, see previous comments. > >> Solution? > > You may want to use a Processor for B (instead of an EventsourcedProcessor) > since the messages emitted by A are anyway *events* and not commands. In > other words, the messages journaled by processor B already represents an > event log, so there's no need to use an EventsourcedProcessor here. > > You could also use an ordinary (non-persistent) actor as destination of the > channel. It receives the Persistent messages, and wraps them in something > else and forwards to the EventsourcedProcessor. Confirmation can then still > be made by the EventsourcedProcessor. > > /Patrik > > > > If at-most-once delivery semantics are sufficient in your use case, you can > also send messages from within a persist() event handler which is not > re-executed during replay. Hence, there's no need to use a channel at all. > > >> >> >> 2 --------- >> Seems one channel message can be confirmed by multiple destination, can I do >> this: >> >> channel forward Deliver(Persistent(payload1), actor_1_ref) >> channel forward Deliver(Persistent(payload1), actor_2_ref) >> channel forward Deliver(Persistent(payload1), actor_2_ref) > > This violates the channel usage rule (separate channel per outbound message) > that we discussed in your previous message. > > >> >> ( why not: channel forward Deliver(Persistent(payload1), Set(actor_1_ref, >> actor_2_ref, actor_2_ref)) >> The same message will only be journaled once? > > When using plain channels, no additional journaling is done when sending the > message over that channel. The API you propose would again break the channle > usage rule. > > >> >> BTW, if we have to do: >> channel forward Deliver(Persistent(payload1), actor_2_ref) >> >> Why cannot we simple drop "Persistent" so we have: >> channel forward Deliver(payload1, actor_2_ref) > > The primary use case of a channel is to filter out confirmed messages that > have been replayed by a processor. Replayed messages are always Persistent > messages, hence the Persistent parameter in the Deliver command. > > Only for standalone channels, it may be more convenient to let the channel > wrap any message into a Persistent message but this is something that can > also be easily done by an application. > > >> >> Sorry if these questions are silly or don't make sense. >> >> On Thursday, February 20, 2014 1:54:25 PM UTC+8, Martin Krasser wrote: >> Hi dong, >> >> On 20.02.14 04:31, dong wrote: >>> I'm been playing with the new Akka persistence module, and have the >>> following questions that I hope to get answered. >>> >>> The document says "If a processor emits more than one outbound message per >>> inbound Persistent message it must use a separate channel for each outbound >>> message to ensure that confirmations are uniquely identifiable..." Is this >>> because that " p.withPayload(...) and Persistent(...) method reuse the >>> current message's id, therefore if we call either method more than once, >>> the processor will emit multiple messages with the same id? >> >> Yes, akka-persistence doesn't generate (and write) new sequence umbers for >> outbound messages. Generating new sequence numbers for outbound messages >> would make this usage rule obsolete but would significantly lower >> throughput. We decided to go for higher throughput. >> >>> I think this implies channels compare new message'd id with the largest id >>> ever seen and discard messages whose ids are smaller or equal to the last >>> id seen, do they？ >> >> No, replayed messages contain information which channel destinations >> confirmed their delivery. If a channel encounters a replayed message that >> contains a confirmation with the same channel id, it ignores that message. A >> confirmation is a persistent (processorId, sequenceNr, channelId) 3-tuple, >> where (processorId, sequenceNr) identify the a persistent message. >> >>> (I guess I should start reading the code.) >>> Were channels designed to be used one-way or two-ways? If my previous guess >>> about channel's id check mechanism is correct, channels should be one-way >>> only. Just want to make sure I'v got it right. >> >> They are one-way. >> >>> If one processor accepts persistence messages from multiple channels, to >>> deal with potential re-deliverying of the same messages, I guess the >>> processor should keep a 'last-seen-id' for each channel and do id-check, >>> right? >> >> Only if you assume that messages cannot be lost. This is reasonable to >> assume for local channel destinations but not for remote >> destinations. >> >>> In a hello-persistence example I'm writing, I used a Casbah mongodb journal >>> plugin (the author is nice btw), I randomly get "Persistent commands not >>> supported" error. Anyone knows what this imply, application logic error or >>> it might be a journal plugin incomparability? >> >> Seems you're sending Persistent messages to an Eventsourced processor. >> Eventsourced processors do not support command sourcing. >> >>> Is there a way to customize message id generation logic? Say I want my id >>> start from 1000000 and increment by rand()%3? >> >> No. >> >>> Thank you :) >>> -- >>> >>>>>>>>>> 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. >>> 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/groups/opt_out. >> >> -- >> Martin Krasser >> >> blog: http://krasserm.blogspot.com >> code: http://github.com/krasserm >> twitter: http://twitter.com/mrt1nz > > -- > Martin Krasser > > blog: http://krasserm.blogspot.com > code: http://github.com/krasserm > twitter: http://twitter.com/mrt1nz > > -- > >>>>>>>>>> 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. > 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/groups/opt_out. > > > > -- > > Patrik Nordwall > Typesafe - Reactive apps on the JVM > Twitter: @patriknw > > > > -- > >>>>>>>>>> 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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @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.
