Replacing AMPQ with Akka

[Vagif Abilov]

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

[Tim Harper]

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).

[Vagif Abilov]

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

[Tim Harper]

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

--
>>>>>>>>>> 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 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.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Vagif Abilov]

Thank you Tim for a comprehensive answer. It makes sense. So in case the message that comes to our system needs to go through a chain of operations with ability to be replayed from the point of failure, you would use a message queue for every chain step rather than building recover logic around actor persistence, did I understood you right?

Vagif