In addition, Akka.NET has some trapdoors in the area of Threading. Become / Unbecome, Stashing and so on can quickly cause performance problems if misused. That's where most beginners fail.
Here are 3 things I would like to know about akka.net earlier.
1. Akka.NET is not (only) a framework. Its a Pattern!
Threading and scaling are basically just one aspect of Akka.
Akka is much more of a pattern that allows you to take "shortcuts" and code in other ways.
Thats the real power of Actors!
If you have Actors that running one big function of Sync/Async Code you not using the Actor Pattern. You need ensure that the Work is splitted and handled with the Messages for natural parallelism. If you Block your Actor with a long running single task, the next messages needs to be wait for Processing. The Result is that the Message throuhput in the local Actor-System is broken.
3. Reliability in Dist-Pub/Sub is not the best.
The problem with the Distributed Pub/Sub System in Akka.NET is the not existent Message-Persistents. You will definitely lose Messages!(Network, Cluster, Actor-Crash, Reboot, Scale, etc..) Although there are possibilities for Message-Persitence and a ACK System, but they are all not really suitable for Production.
If the MQ-System is important you should use another one that forward the Messages to the Actor-System. EasyNetQ is for example a robust and simple solution on top of RabbitMQ.
Top comments (3)
Hey, that looks really detailed. However, I would recommend in practice a "lighthouse container". This can greatly simplify scaling in Kubernetes.
github.com/petabridge/lighthouse
In addition, Akka.NET has some trapdoors in the area of Threading. Become / Unbecome, Stashing and so on can quickly cause performance problems if misused. That's where most beginners fail.
Here are 3 things I would like to know about akka.net earlier.
1. Akka.NET is not (only) a framework. Its a Pattern!
Threading and scaling are basically just one aspect of Akka.
Akka is much more of a pattern that allows you to take "shortcuts" and code in other ways.
Thats the real power of Actors!
Old way
![alt](https://res.cloudinary.com/practicaldev/image/fetch/s--lQA50VrV--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://doc.akka.io/docs/akka/current/guide/diagrams/seq_chart.png)
![alt](https://res.cloudinary.com/practicaldev/image/fetch/s--Gzc_eANz--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://doc.akka.io/docs/akka/current/guide/diagrams/object_graph.png)
New ways..
Link to Akka.io, the java implementation
2. Slow Actors, Slow System
If you have Actors that running one big function of Sync/Async Code you not using the Actor Pattern. You need ensure that the Work is splitted and handled with the Messages for natural parallelism. If you Block your Actor with a long running single task, the next messages needs to be wait for Processing. The Result is that the Message throuhput in the local Actor-System is broken.
3. Reliability in Dist-Pub/Sub is not the best.
The problem with the Distributed Pub/Sub System in Akka.NET is the not existent Message-Persistents. You will definitely lose Messages!(Network, Cluster, Actor-Crash, Reboot, Scale, etc..) Although there are possibilities for Message-Persitence and a ACK System, but they are all not really suitable for Production.
If the MQ-System is important you should use another one that forward the Messages to the Actor-System. EasyNetQ is for example a robust and simple solution on top of RabbitMQ.
I hope this helps you further ;)
Thanks a ton for taking time to share. Definitely helps ;) keep writinf