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.
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 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
<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
<http://groups.google.com/group/akka-user>.
For more options, visit https://groups.google.com/groups/opt_out
<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].
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.
