Okay, My comment wasn't indented to imply that persistent actors would not work here, but rather that RabbitMQ is robust, solid software, and removing it probably cause you to reimplement a lot of things that RabbitMQ already does for you. I think that getting rid of RabbitMQ is likely to increase your complexity, rather than reduce it.
Some things that come to mind: - RabbitMQ has dead-letter exchange support, which can handle delayed redelivery of your messages - RabbitMQ provides a nice GUI to monitor the state of your message queues, and allows you to reach your hand into a queue, pull a message out, look at it, and put it back in. - RabbitMQ offers multiple durability options (persist to disk, publish to replica, both) - RabbitMQ has a great publisher confirms solution, which allows you to pay for message persistence confirmation with latency, rather than CPU or excessive fsync calls. You can implement these features using Akka, sure; but why? They're hard problems. Just use RabbitMQ. It's battle tested and it's one less custom thing everyone on your team will need to learn. Tim > On Dec 2, 2015, at 04:05, Vagif Abilov <[email protected]> wrote: > > Thanks, Tim. No, I haven't looked at op-rabbit (I am using Akka.Net with C# > and F#). I wonder then why this is not right use of persistent actors and > what is the right one then. I guess I will need to play with actor model more > to better understand it. > > Vagif > > On Tuesday, December 1, 2015 at 11:55:17 PM UTC+1, Tim Harper wrote: > My knee jerk reaction is no: not a good idea. I think the scheme you describe > of using persistent actors will increase your complexity. > > Have you looked at op-rabbit? (are you using Scala?). It encodes the very > pattern you describe in a way that keeps the complexity out of your codebase. > It's well tested and is being used in several production environments (of > which I'm aware). > > > > On Tuesday, December 1, 2015 at 1:10:37 AM UTC-7, Vagif Abilov wrote: > Hi, > > I am quite new to Akka and am currently investigating if it's a good idea to > replace some of our logic built around AMPQ (RabbitMQ) with Akka and actor > model. Here's one of our scenarios: > > 1. Receive a message from RabbitMQ. > 2.1-2.n Perform several operations, some of them in a transaction scope. > 3. Ack the RabbitMQ message if performed operations are OK, otherwise Nack > the message and replay it with some configurable delay. > > We think that step (3) is rather complicated and would like to stop using > RabbitMQ as a part of distributed transaction. We would rather ack the > message right upon its arrival and deal with possible failures using > persistent actors. So I am trying to figure out what would be the right > transition to Akka now that we have: > > - An incoming message that we need to be able to replay in case of an > operational failure. > - A sequence of actors triggered by the message processing, each of them may > fail > > Questions: > > 1. Do we need to make each actor persistent in order to ensure it can replay > incomplete messages? > 2. Will the actor persistence solve the problem of replaying unprocessed > messages in case of system outage? > 3. Can different persistent actors use different physical stores even though > they are part of the same deployment unit? > 4. What if we decide to move an actor between deployment units or machines? > How can we make its event history follow the actor? > > Thanks in advance > > Vagif > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>> 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 a topic in the Google > Groups "Akka User List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/akka-user/ber7uS-_x2c/unsubscribe > <https://groups.google.com/d/topic/akka-user/ber7uS-_x2c/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > 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/d/optout > <https://groups.google.com/d/optout>. -- >>>>>>>>>> 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.
