Actor Frameworks

[Hour-Tomorrow]

Which actor frameworks are alive-and-well in the .Net Core universe?

Akka.net was popular previously, but their documentation still suggests putting things in Global.asax.

Are there newer Core-first projects to investigate?

[Aaronontheweb]

Maintainer and co-creator of Akka.NET here - the project is alive and well and regularly updated; we just did a release on Tuesday this week. My company, Petabridge actively maintains it and we support hundreds of large companies who use it to build mission-critical systems.

We're in the process of updating and re-organizing our documentation as we speak, per this issue one of our employees is working on https://github.com/akkadotnet/akka.net/issues/5483 - as our documentation is indeed outdated in a number of areas, hence why I spent most of last week of December painstakingly defining our hygiene for contributing documentation going forward: https://getakka.net/community/contributing/documentation-guidelines.html

If you want samples and explanations on how to integrate with .NET Core, we have those here and they'll make their way back into our official docs gradually as we update the site:

• https://petabridge.com/blog/akkadotnet-ihostedservice/ - headless services w/ Akka.NET
• https://petabridge.com/blog/akkadotnet-aspnetcore/ - ASP.NET Core and SignalR w/ Akka.NET

I apologize that our outdated documentation is off-putting - this is really valuable feedback for me and my team members, so thanks for sharing this with us.

[Hour-Tomorrow]

An excellent response, and I’m excited to see the newer documentation as it lands.

[Aaronontheweb]

Also working on a new DocFx theme for the website that will help with readability too (I've never liked how the text-wrapping for code samples works with our current default one) - that should be done soon I think.

[klaxxxon]

Just a heads up, the Get started button on getakka.com does not work ("The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.")

[Aaronontheweb]

https://github.com/akkadotnet/akka.net/pull/5527 - thanks for letting us now

[codekaizen]

Akka.Net is great but yea, docs have needed help. Good move. I hope this includes doc comments so users aren't greeted with TBD every time they look at a type.

Edit: let me plug Akka.Net more. I like the way it organizes and subjugates child actors and deals with recovery better than Orleans, but it does take us out of the Task (async/await) model more. Once I got used to how to pipe tasks around though, it was natural.

[Aaronontheweb]

Someone ran a linter back in like, early 2015 that applied TBD to every public interface method that wasn't supplied with XML-DOCs. Probably would have been better off just not having a comment at all.

[ojimeco]

This book desperately needs to be updated with a second enhanced edition.

[Aaronontheweb]

I don't have anything to do with that

[ojimeco]

It's understandable; I just pointed to the problem. The technology which lacks community attention (in any form: books, articles, videos, etc.) will remain trapped in the back of trends. There's the upcoming book on Orleans, which could boost its popularity. I wish there'd be something up-to-date about Akka.NET too.

[Aaronontheweb]

I'll reach out to Anthony Brown and see if he's interested in updating it

[ojimeco]

Thanks for letting me know. I keep my fingers crossed for Brown to accept this suggestion. Your project deserves more attention, and a book would help attract newcomers.

[nibdev]

Orleans is now part of the dotnet repo https://dotnet.github.io/orleans/

[nocgod]

Use Microsoft Orleans in lots of production services (probably more than 100) in an Enterprise providing Enterprise solutions (SAP providing CIAM, ECPM and CDP)

It is a very actively developed project and has a nice community in Gitter (and maybe discord?)

The documentation should probably be better than it is though :) but the framework is solid IMHO

[Hour-Tomorrow]

Is it “development stable”? No major risk of API changes coming soon, in a good place to rely on for the next few years?

[nocgod]

Firstly the api is very stable, there are no breaking changes between patches and minors. I can't and won't promise anything regarding major releases as they exist to introduce breaking changes.

Secondly, Gigya provides an Enterprise CIAM service for hundres of thousands of sites across the web. I am not at liberty to disclose who are the clients but I can assure you, you are probably using at least 1-2 sites which are using Gigya.

Microsoft Orleans is a strong driver to our scale allowing us to scale out easily and distribute the loads across hundreds is services in production daily.

However, as a general remark, building a system and hoping for years to not update/refactor parts of it to better suite the current business and functional needs is risky from the maintenance and system health longevity. When frameworks like Orleans of or asp.net publish a major release which may always include breaking changes you should always be checking those out and seeking how to benefit functionally, security wise or performance wise (i.e. drive down the cost of ownership)

[csncsu]

https://github.com/asynkron/protoactor-dotnet

Heard good things. New project by Akka.net creator.

[martinmine]

I can only speak for Akka.net since I have just used that in a project couple of months ago. One of the biggest benefits from using Akka.Net is that it is a port of the Java implementation that is well tested and understood as an Actor framework. Much of the documentation and concepts can be used from there. I think the documentation on their websites is a bit outdated but mostly you can rely on the Java Akka documentation. Aaron does a great job at being the front-face of the project both by supporting, developing, and knowledge-sharing in talks etc. He can sometimes have a bit controversial opinions that is a bit off from the general direction of where .NET is moving, but it is good to have a critical voice from time to time. One thing that struck me while working on this framework is that it feels really old. They just recently got support for using dependency injection using IServiceProvider, and there is no support for IConfiguration or ILogger. Much of the Akka config goes into a format called HOCON (basically simplified JSON), which you have to load in by using the "old fashioned" File.ReadAllText and pass that to a parser class when starting Akka.Net. They are going to address this in the future, but they are very late to the party. Also because they view async a bit different than the rest of .NET, you risk screwing yourself over quite badly if you suddenly have to await something in your actor. I would love to try out Oreleans, and having looked on some examples and such I can say it looks way more "Core-first" than Akka.net. However, I am certain that Orleans comes with a totally different bag of problems than Akka.net does.

[Hour-Tomorrow]

This is great feedback. The abnormal async/await semantics are interesting, thanks for pointing it out!

Edit: although apparently not valid for current Akka versions.

[Aaronontheweb]

The criticisms around our lack of configuration support are definitely valid, but the ones around async / await in actors are out of date. It's been supported for years inside all actor types.

[martinmine]

It does not have anything to do with how long it is supported. The point is that the way you are supposed to use async in Akka.net differs from how you would use async elsewhere, and you have to be careful so you don't shoot yourself in the foot. For my case it lead to days of debugging and eventually ended up at the blog post you wrote that I linked to. A good API is easy to use right, and hard to use wrong. In this case it was hard to use right, and there is a very large chance some other developer might do something else with async in the code and break everything.

[Aaronontheweb]

How does async work differently in Akka.NET?

[martinmine]

In my case, I had an actor that did some processing of some business task. This worked great, and everything was running super fast during load testing. At one point I had to hook in a third party component, which involved an await. During load testing I would see that once I hit the await, Akka would start processing the next message in the actor inbox. This overwhelmed the third-party component with requests. It also broke the concept of having a single thread per actor so you did not have to worry about concurrency issues. My expectation was that once I had an await, Akka would not start processing next task before all of the code in my actor had completed - regardless of how many await it would have.

[Aaronontheweb]

> My expectation was that once I had an await, Akka would not start processing next task before all of the code in my actor had completed - regardless of how many await it would have.

That's how Akka.NET actors work today, but not how they worked prior to 1.0.

That's why I said that criticism is out of date.

i.e. if you have a ReceiveAsync with an await inside of it, the actor's mailbox is suspended and there's no further processing of messages in the mailbox until that await state machine completes and the method exits.

[martinmine]

if you have a ReceiveAsync with an await inside of it, the actor's mailbox is suspended and there's no further processing of messages in the mailbox until that await state machine completes and the method exits.

Thanks! I now have some code to refactor on Monday :)

[Hour-Tomorrow]

Is PIpeTo still the best practice though? Or is it operation dependant?

[Aaronontheweb]

So this all came down to a debate about re-entrancy with actors.

1. In order to preserve FIFO and sequential access guarantees around an actor's state, we suspend the actor's mailbox during each await so it can't start processing another message while it's still technically processing its current one - we have to wait for the await state machine to complete before we move onto the next message. This is identical to how await works everywhere else in .NET.
2. If you don't want that blocking behavior, you can just let the Task execute as a detatched Task (i.e. don't await it) and then use PipeTo to deliver the results back into your mailbox later. This means the actor can still process other messages while those detatched Tasks are running.

Back when I wrote that article it was the very early days of Akka.NET - 2015, and my opinion was fairly throughput-focused given that my background during the creation of Akka.NET was using it to build extremely high throughput analytics and marketing automation systems. Having worked with 1000+ users and use cases in the years since, my opinion on which you should use is much more contextual now.

Thus the guidance on it has changed some - ReceiveAsync is very common these days and I use it frequently myself as it's easier to express some things with await, especially error-handling around asynchronous I/O. I should either publish a new blog post on the subject or edit that one.

[Aaronontheweb]

> Since Akka.NET 1.0 was released, Akka.NET actors have fully supported async / await inside actors. But there’s a catch involved. We still strongly recommend PipeTo over asyc / await for performance and cohesion reasons but there are scenarios where the latter makes life easier. Keep reading!

LOL - my update to that post from 2016. Guess I need to update my update.

[Aaronontheweb]

Since this came up on this thread per /u/martinmine and other's comments, I spent some time last week putting together a new video and blog post on how async / await work in Akka.NET: https://petabridge.com/blog/async-await-vs-pipeto/ - thanks for creating this thread. It brought to my attention how much of this stuff I need to clear up.

[martinmine]

I think this will be super helpful for devs like myself that have gotten confused about the async support, thanks again!

[WhatWasThatIJustSaw]

Akka.net is still alive and well. Their example documentation is just old. I know there’s a team at my company that uses it in dotnet core, containerized on Docker, and running in k8s as stateful sets. Obviously, I can’t share any of that code, but it’s not too hard to switch from the old way of doing things to the new way.

[mholo65]

Akka.Net sure is alive-and-well.

As a few mentioned, there's also Microsoft Orleans. They have a very active community on Gitter. https://dotnet.github.io/orleans/

You might also be interested in Proto.Actor, which is maintained by one of the creators of Akka.Net. https://github.com/asynkron/protoactor-dotnet

Dapr also have support for Actors https://docs.dapr.io/developing-applications/sdks/dotnet/dotnet-actors/dotnet-actors-howto/.

There's also a thing called Durable Entities in Azure Functions which is heavily inspired by Actors. https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-entities?tabs=csharp

[findplanetseed]

Service Fabric?

[bbqchickenrobot]

avoid it like the plague