Hi, I'm not sure that I understand your use case (you ask a lot of detailed questions). I think it would be much better if you asked about what you want to accomplish at higher level.
The fundamental use cases for the akka-persistance are Command Sourcing and Event Sourcing. There was recently a discussion in this thread about Channels and some confusion around them and maybe even removing the Processor (Command Sourcing) in favor of a completely event sourced approach using the EventSourcedProcessor. Anyway, I've tried to answer your questions. On 10 May 2014 at 10:39:35, Luis Medina ([email protected]) wrote: So I finished reading the section on the Akka documentation about Persistence and I also played around with the "akka-sample-persistence" Typesafe Activator project and had several questions about it. Please bear with me if some of the questions seem dumb; I'm just trying to make sure I understood things correctly. Here we go: 1. Since a Processor actor persists Persistent messages that are sent to it, is there a limit to how many it can "save"? I'm guessing this is probably based on the disk size of the machine by default since it uses LevelDB (a.k.a. the local file-system). Yes, there is no general limit on the number of messages that can be saved (apart from the journal running out of storage). A journal plugin is of course free to implement settings that set limits on the size of journals to be saved. 2. This is probably a pointless question but I just want to double check. When a Processor deletes a message using the "deleteMessage" method, it's removed completely from its journal (and thus the system) right? Seems like something to consider if you start running out of disk space from journaling. If your underlying journal supports deletion , then messages will be deleted. There can be journals where you can't delete arbitrary messages, but have to drop all messages up to a certain point. 3. Transient channels are mainly used to avoid re-delivery of a Persistent message that has been sent to a destination from a Processor. Once the destination confirms that it received a ConfirmablePersistent message from a transient channel using the "confirm" method, the documentation says that this "...asynchronously writes a confirmation entry to the journal". Is this confirmation entry stored in the journal of the Processor actor that originally sent the message or do transient channels have journals of their own? The transient channel will have a journal of its own for the confirmation entries, since they are for the Channel and not the Processor. 4. Say I have a scenario where a Processor actor pulls 10 elements from some 3rd party data store. After it has pulled these elements, can I wrap each one in a Persistent message and have the processor send them to itself in order to persist them? Yes, a Processor can send Persistent(...) messages to itself to persist them, but what would it mean if you failed after persisting only a few of them, or before persisting any of them? 5. On the Akka documentation for Persistence, it states that: 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, otherwise, at-least-once message delivery semantics do not apply. a. Does this mean that a channel can only be used simultaneously for a single inbound message and a single outbound message (ie. it can have 2 messages at most at any given time; one outbound and one inbound)? You can have many messages in flight, but it means that the confirmation is stored per message per channel (and processor), and there is no way to distinguish two different acknowledgements if you send the same message via the same channel to two different destinations. This coupling between the incoming Persistent message and the outgoing message on the channel is used to be able to avoid re-sending already acknowledged messages when a processor is restarted. b. Is this implying that the outbound messages that the Processor is sending is being done through the channel (I'm guessing doing a "tell(...)" to an actor, for example, doesn't factor into this)?. This is only relevant for channels. c. If there is a scenario where I have a master Processor actor that sends a message to each of its 5 children using channels and I expect a confirmation from each one of them, will I need to have 5 different channels (one for each child)? If you emit messages as a response to an incoming Persistent message then you would have to have one channel per destination for that message. The thing that I'm wondering though is what you want to accomplish at a higher level. Do you really need the confirmation at this step? If your children are local you can be fairly certain, as long as your application doesn't crash, that the messages will be delivered. 6. Is it safe to say that having either a: (a) Processor actor (with Persistent messages being sent to it) that uses a normal/transient channel or a (b) regular UntypedActor that uses a persistent channel (ie. using persistent channels standalone) are the same in terms of providing persistence to the messages they are being sent by their respective actors? The way I see it, in case (a) a message is being persisted by the Processor actor itself inside its journal while in case (b) the message is being persisted by the persistent channel. The difference, it seems, would be that a persistent channel will delete a message once a destination confirms its delivery while in a Processor, you would have to manually tell it to delete a message with the "deleteMessage" method. You are in principle correct, if you only want to use the Processor to keep track of messages delivered to some destination. Usually the Persistent messages sent to your Processor is used to build up some internal state of the Processor as well. 7. Does a persistent channel have its own journal that it uses to persist messages? If so, is this journal saved on disk or in-memory and is it configurable similar to how a Processor's journal? If not, then how do persistent channels persist messages? Persistent channels have their own journals. 8. Can persistent channels and Processors be used together? The reason I ask is because since they both do their own form of persistence, I don't know if this would be persistence overkill. Yes they can be used together, but that would be a different thing than using a transient channel. A persistent channel will delete the messages that have been confirmed, and if restarting your processor results in sending the messages again, then they will be sent again. B/ -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> 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/d/optout. -- Björn Antonsson Typesafe – Reactive Apps on the JVM twitter: @bantonsson JOIN US. REGISTER TODAY! Scala Days June 16th-18th, Berlin -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> 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/d/optout.
