How Akka Cluster Works: Actors Living in a Cluster
lightbend.com
How Akka Cluster Works: Actors Living in a Cluster
1–10 of 65 posts
Re: How Akka Cluster Works: Actors Living in a Cluster
#2In scala-land, a lot of people like to scoff at Akka because they prefer other pure fp concepts, but I don't think they've found a replacement for Akka Cluster - where you need objects that have both state and behavior, meaning they need to exist in memory, and where there are too many to exist on one server.
If you don't need behavior, you can use things like distributed databases or caches, and if you don't need to scale out, there are other pure fp solutions. But for this kind of distributed behavior, it still seems to me that Akka Cluster is the killer app.
Re: How Akka Cluster Works: Actors Living in a Cluster
#3Wait, what, are you saying Akka Clusters “works”
Re: How Akka Cluster Works: Actors Living in a Cluster
#4I've written a high-availability service with Akka.NET and RabbitMQ and I remember when I was working with that infrastructure, my biggest question around Akka Cluster was "why would I use this when I already have a message queue infrastructure?"
Maybe real Akka is better than Akka.NET when it comes to Akka Cluster?
Re: How Akka Cluster Works: Actors Living in a Cluster
#5I've written a high-availability service with Akka.NET and RabbitMQ and I remember when I was working with that infrastructure, my biggest question around Akka Cluster was "why would I use this when I already have a message queue infrastructure?" Maybe real Akka is better than Akka.NET when it comes to Akka Cluster?
Queues overlap with the messaging aspects of actors but not the supervision aspect of actors.
Re: How Akka Cluster Works: Actors Living in a Cluster
#6Carl 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 would be interested to know people's opinions on this, as a lot of the paper went over my head.
Re: How Akka Cluster Works: Actors Living in a Cluster
#7I 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 discovery system on top of Zookeeper. Using that, I could have a cluster-wide unique actors.
Re: How Akka Cluster Works: Actors Living in a Cluster
#8I've written a high-availability service with Akka.NET and RabbitMQ and I remember when I was working with that infrastructure, my biggest question around Akka Cluster was "why would I use this when I already have a message queue infrastructure?" Maybe real Akka is better than Akka.NET when it comes to Akka Cluster?
Queues overlap with the messaging aspects of actors but not the supervision aspect of actors.
For that we have cluster management like kubernetes
Re: How Akka Cluster Works: Actors Living in a Cluster
#9Earlier quoted context omitted.
Queues overlap with the messaging aspects of actors but not the supervision aspect of actors.
For that we have cluster management like kubernetes
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).
Re: How Akka Cluster Works: Actors Living in a Cluster
#10Earlier quoted context omitted.
For that we have cluster management like kubernetes
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