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.
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 > <[email protected]<javascript:> > > 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<http://doc.akka.io/docs/akka/2.3.0-RC4/scala/persistence.html#processors>). >> >> Applications directly send a Persistent messages to a processor. You can >> think of a processor maintaining a write-ahead-log. >> >> An >> EventsourcedProcessor<http://doc.akka.io/docs/akka/2.3.0-RC4/scala/persistence.html#event-sourcing>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<http://doc.akka.io/docs/akka/2.3.0-RC4/scala/persistence.html#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<http://doc.akka.io/docs/akka/2.3.0-RC4/scala/persistence.html#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. >>> >>> >>> 1. 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 Persi >>> stent(...) 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. >>> >>> >>> 1. 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. >>> >>> >>> 1. (I guess I should start reading the code.) >>> 2. 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. >>> >>> >>> 1. 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. >>> >>> >>> 1. 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. >>> >>> >>> 1. 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 [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/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 [email protected] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> 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 <http://typesafe.com/> - 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 [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/groups/opt_out.
