Martin, thank you for the quick reply. Great work on AKKA persistence, we are very likely to use it in production. So more questions might come to you later.
1 --------- What do you mean " Eventsourced processors do not support command sourcing. "? 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? Solution? 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) ( 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? 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) 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 > 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. > > > 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 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. > > > -- > 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+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.
