Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Akka Cluster Works: Actors Living in a Cluster

lightbend.com

Post reply on HN
Print view View original

11–20 of 65 posts

Re: How Akka Cluster Works: Actors Living in a Cluster

#11

Post by hilbertseries »

jpcooper wrote: post #6

Carl Hewitt, the inventor of the actor model, wrote this paper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003 , which he posted a link to on a recent post here on Erlang. In it, he claims that Godel's Incompleteness Theorem is not true, and that the actor model is more general than the Turing machine. I am open to entertaining the idea. I've seen that his ideas have been discredited elsewhere on HN. I w…

> he claims that Godel's Incompleteness Theorem is not true, and that the actor model is more general than the Turing machine

He is certainly wrong about the incompleteness theorems. And it’s entirely possible to create a model of computation that is more general than Turings. The question is whether it better represents what’s computable, the abstract mentions computations involving an “infinite number of computations” between steps...

Re: How Akka Cluster Works: Actors Living in a Cluster

#12

Post by tunesmith »

t-writescode wrote: post #10
29athrowaway wrote: post #9

Earlier quoted context omitted.

An actor can fail for reasons other than infrastructure issues. i.e.: unhandled exceptions. In fact, unhandled exceptions are encouraged (i.e.: "let it crash" approach to fault tolerance).

Sure, but that’s almost entirely local within a process, where regular Akka processes would work. So, in the system I worked with, individual applications were Akka powered and cross-process/cross-vm communication was done through queues

What if you have a message that is specifically for another actor that may or may not be on the same server?

Re: How Akka Cluster Works: Actors Living in a Cluster

#13

Post by t-writescode »

tunesmith wrote: post #12
t-writescode wrote: post #10

Earlier quoted context omitted.

Sure, but that’s almost entirely local within a process, where regular Akka processes would work. So, in the system I worked with, individual applications were Akka powered and cross-process/cross-vm communication was done through queues

What if you have a message that is specifically for another actor that may or may not be on the same server?

That doesn't exist in the models I've designed. Microservices still exist and they each do their requisite task, but different work is done by different actors in the actor cluster. Actors are still a fantastic way of handling concurrency, since they can each be treated as single-threaded tiny programs that only think about themselves, and so I've used them in that way.

The actor just won't exist elsewhere, but another microservice that happens to use actors might exist. It would be sent a web request or a message in queue or similar.

Re: How Akka Cluster Works: Actors Living in a Cluster

#14

Post by halfmatthalfcat »

I use Akka Cluster extensively with Persistence. It's an amazing piece of technology.

Before I went this route, I tried to make Akka Cluster work with RabbitMQ however I realized (like another poster here) that you're essentially duplicating concerns since Akka itself is a message queue. There's also a ton of logistics with Rabbit around binding queues, architecting your route patterns, etc that add extra cognitive overhead.

I'm creating a highly distributed chat application where each user has their own persistent actor and each chatroom has their own persistent actor. At this point, it doesn't matter where the user or chatroom are in the cluster it literally "just works".

All I need to do is emit a message to the cluster from a user to chatroom or vice versa, even in a cluster of hundreds of nodes, and things just work. Now there's some extra care you need to take at the edge (split-brain via multi-az, multi-datacenter) but those are things you worry about at scale.

Akka is the real fucking deal and it's one of the most pleasurable application frameworks I've ever had the pleasure of using in my career.

edit: The only reason I'd ever want to use Rabbit again is if I had external clients that needed to hook up to our message bus. If you're creating an entirely internal system, Akka Cluster is absolutely the way to go.

Re: How Akka Cluster Works: Actors Living in a Cluster

#15

Post by halfmatthalfcat »

29athrowaway wrote: post #7

I used Akka cluster many years ago. One of the problems I encountered was that to finding actors in remote actor systems. i.e.: you have a unique actor responsible for X, living somewhere in your cluster and you need to know its name as well as the IP address of the actor system where it is running. A message queue solves this problem, but that was not the approach I took. My solution was to implement an actor discov…

They have Cluster Singletons that alleviate this concern now. You don't need to know their physical location in the cluster. All you need to do is ask the cluster for a pointer to the Singleton and you can message it directly.

Re: How Akka Cluster Works: Actors Living in a Cluster

#16

Post by amelius »

halfmatthalfcat wrote: post #14

I use Akka Cluster extensively with Persistence. It's an amazing piece of technology. Before I went this route, I tried to make Akka Cluster work with RabbitMQ however I realized (like another poster here) that you're essentially duplicating concerns since Akka itself is a message queue. There's also a ton of logistics with Rabbit around binding queues, architecting your route patterns, etc that add extra cognitive o…

Could one implement a distributed filesystem using Akka?

Re: How Akka Cluster Works: Actors Living in a Cluster

#17

Post by halfmatthalfcat »

t-writescode wrote: post #10
29athrowaway wrote: post #9

Earlier quoted context omitted.

An actor can fail for reasons other than infrastructure issues. i.e.: unhandled exceptions. In fact, unhandled exceptions are encouraged (i.e.: "let it crash" approach to fault tolerance).

Sure, but that’s almost entirely local within a process, where regular Akka processes would work. So, in the system I worked with, individual applications were Akka powered and cross-process/cross-vm communication was done through queues

With Cluster + Sharding you can have zero(ish) downtime though when you scale horizontally. Messages sent to Sharded actors are buffered if their nodes ever go down and things will just resume as normal.

Re: How Akka Cluster Works: Actors Living in a Cluster

#18

Post by halfmatthalfcat »

amelius wrote: post #16
halfmatthalfcat wrote: post #14

I use Akka Cluster extensively with Persistence. It's an amazing piece of technology. Before I went this route, I tried to make Akka Cluster work with RabbitMQ however I realized (like another poster here) that you're essentially duplicating concerns since Akka itself is a message queue. There's also a ton of logistics with Rabbit around binding queues, architecting your route patterns, etc that add extra cognitive o…

Could one implement a distributed filesystem using Akka?

You could but I don't think it would be the best tool for it. When I think of Akka, I'm using it because I don't want to worry about which node in my cluster any given actor is on, I just want to be able to scale horizontally and messages are routed appropriately.

Akka embraces the "let it fail" mentality where as nodes go down (just as pods go down in Kuberentes), you don't have to worry about where your processes are running...they just are...somewhere.

Re: How Akka Cluster Works: Actors Living in a Cluster

#19

Post by t-writescode »

halfmatthalfcat wrote: post #17
t-writescode wrote: post #10

Earlier quoted context omitted.

Sure, but that’s almost entirely local within a process, where regular Akka processes would work. So, in the system I worked with, individual applications were Akka powered and cross-process/cross-vm communication was done through queues

With Cluster + Sharding you can have zero(ish) downtime though when you scale horizontally. Messages sent to Sharded actors are buffered if their nodes ever go down and things will just resume as normal.

You can have that with a queueing system, too. As long as you don't ack the message before you're done processing it, the messages that are processing will be sent to the next available client on crash

Re: How Akka Cluster Works: Actors Living in a Cluster

#20

Post by halfmatthalfcat »

t-writescode wrote: post #19
halfmatthalfcat wrote: post #17

Earlier quoted context omitted.

With Cluster + Sharding you can have zero(ish) downtime though when you scale horizontally. Messages sent to Sharded actors are buffered if their nodes ever go down and things will just resume as normal.

You can have that with a queueing system, too. As long as you don't ack the message before you're done processing it, the messages that are processing will be sent to the next available client on crash

Sure but the point is it's built into Akka. If you're looking to replace an external queue system, Akka will replace most if not all of it's functionality.
Post reply on HN