I notice you are using a MySQL DB, if you need a connected durable mail box there were a few options, just like there are a few options with Akka Persistence. I'm currently working on a SQL Akka Persistence extension using Slick 2 which will work with MySQL, PostgeSQL, H2 etc. I'm planning to open source it (just needs a bit of cleanup in the config - if you're interested I can send you a copy, it would be good to get some feedback).
It is no harm to delete messages after you process them. We are using Akka Persistence to do just that. We have a work delegator processor which receives Persistent(DoWork(jobx)) which fires up child actors to do some processing. The messages in case of a JVM crash/shutdown will pick up processing from where they left off. Thats one thing that was a problem with durable mailboxes, if the JVM crashes, the current message being processed would be lost, there was no ack. As soon as a message was taken out of the mailbox it was gone so to speak. WRT deleting messages, you have a number of options, the easiest is to take the seq number and when the job has been completed, delete it by calling deleteMessage(seqNum) from within the processor. The other option is to keep track of processed and processing messages and periodically call deleteMessages(seqNum) once processing is acked as completed. We actually use this approach as our message processing is idempotent and message delete is just house keeping so doing it in batch is a little quicker. The other option you can consider is using a Persistent Channel. These will give you what you require, from the doco; Persistent channels are like transient channels but additionally persist messages before delivering them. Messages that have been persisted by a persistent channel are deleted when destinations confirm their delivery. The current implementation will mark these as permanently deleted https://github.com/akka/akka/blob/master/akka-persistence/src/main/scala/akka/persistence/PersistentChannel.scala#L231 On Tuesday, June 3, 2014 3:04:58 AM UTC+10, Martin Simons wrote: > > Hello List, > > I have a question similar to one posted onto this list before > <https://groups.google.com/forum/#!topic/akka-user/9f-J2PS1IYA>, but a > little bit more specific. > > This is the initial situation: > > - I have an existing application that uses MySQL as its backend. > - Akka is already used extensively in this application. > - The introduction of additional systems/backends should be avoided. > > I'll illustrate my problem using a variation of the classic "bank account > example", an accounting system: Let's say there's an AccountingActor that > handles messages of the type Booking. Whenever a Booking is received, the > AccountingActor opens a database transaction, executes the booking (debits > a given amount from one account and credits it to another) and commits the > transaction. The point here is that many such actors can exist at any given > time, each one representing the accounting of a single entity and thereby > ensuring that Bookings for any such entity are applied in sequence. > > So far, so good: This works perfectly fine as the affected database > records are entity-specific (InnoDB does its row-level transaction magic) > and no indexes are touched. Hence, executing many Bookings in parallel > causes no considerable performance issues. > > Now I'm in the situation that I want to keep the bookings themselves so I > can display a "balance statement" and generate other more complex reports > (that's why the data has to be stored in a relational database in the first > place). All of the bookings are written to the same table in the database > and when dozens of actors are trying to do so in parallel, this naturally > causes locking issues on the database indexes and completely destroys > performance. > > So I'd like to split the operation in two parts: First, execute the > booking as described above, thereby changing the entity's state. After > successful completion of the transaction, I'd like to forward the Booking > to another actor which does nothing else but maintaining the Bookings table > (appending new bookings, pruning old ones). The queue of this actor should > be durable so - in case the system goes down before all of the Bookings > have been persisted - it can continue its work after restart. > > My question now is: Durable Mailboxes seemed like exactly the thing I > need, but they have been removed from Akka and replaced by Akka > Persistence. In the post I linked to in the introduction, two possible > approaches are outlined of which only the first one looks like what I'm > looking for (immediately deleting messages once received/handled by a > Processor). Yet, it kind of feels like using a feature actually designed > for other cases to solve the problem (aka "a hack"). Am I correct in this > perception or is this actually the recommended way to do this? > > Thank you very much for your suggestions. > -- >>>>>>>>>> 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.
