For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
suin -
Guillermo Quiros -
Sacha Thommet -
Sacha Thommet -
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
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