Many actor frameworks (including Orbit, though I advise you don't use it for the reasons in my above messages) are strictly single threaded in that only one thread can operate on an actor at any one time, and by default they are also not concurrent in that only one message gets processed at once.
However, while the single-threadedness is a hard requirement and behavior of the system, the rule that only one message is processed at a time is not.
In Orbit (and Orleans) the ability to process multiple messages at the same time is called reentrancy. it can be specified at the actor or method level usually.
So in your example, say your initial message kicks off a write that is going to take 30 seconds. You start the write and assuming it's async, the actor then suspends while it waits for that to complete. While the actor is suspended another message asking for the progress arrives and that message is reentrant, it can process that message and respond with the progress, then the actor suspends again and at some point another reentrant message arrives or the initial write finishes and the first message finally gets a response. If a none reentrant message is received it will queue in the mailbox until after the first one is completed.
So, with reentrancy you still get the single threaded guarantee but you effectively get interleaving of messages when the actor is suspended waiting for some other async task to complete. This means that if you have an actor with reentrant messages you have to make that code safe to run during any potential interleaving point in another message (for example an await in async C#).
Other actor frameworks (particularly ones that are not based on virtual actors) may have different guarantees and behaviors but from what I've seen there is always some equivalent.
Doesn't reentrancy defeat the serial processing property that makes locks unnecessary? If a new message is accepted before the previous one has finished processing, then it can change the mutable state inside the actor. Essentially, you can never know what the state will be because at any blocking point some other message can make arbitrary changes. At that point the actor is just a crappy class with message passing instead of method calls and all the annoyances that entails.
So, I'm the original lead developer of this project.
This was meant to be a followup to the original version of Orbit which now lives on as orbit-legacy on GitHub.
Unfortunately other priorities have meant this project hasn't proceeded in the past couple of years. I wouldn't really recommend anyone use either of them.
However, the ideas and implementation both for Orbit Legacy and the early version of Orbit 2 contain some ideas and concepts that may be useful to folks.
I still think there is immense value in virtual actors (Orleans from Microsoft is one great alternative for .NET, and Dapr also looks interesting) but I can't say if we'll ever get back to it.
I'm a Dapr early adopter. It's cool and the SDKs are improving a lot, but there are some quirks. I've found that some blocks (connectors) that are listed as general availability are unstable to the point of being useless, while some blocks listed as alpha work fine.
I think the JVM and particularly Java are in desperate need of improvements to the concurrency model.
When I compare the concurrency model on the JVM (and especially Java itself) to the modern competition from the likes of GoLang and C# there are clear and obvious drawbacks. Even comparing just the Java language and some other JVM languages like Kotlin and Scala, it comes up well short.
Project Loom certainly looks to be a step in the right direction. I haven't looked at it in depth recently but Virtual Threads and Continuations will be a welcome addition and last time I did look it was promising in terms of implementation.
If I were creating a new project today I'd likely reach for GoLang or DotNet (now that Core and Framework are unified) before the JVM, and if I did decide on the JVM I'd choose Kotlin over Java.
I'm historically a huge fan of the JVM and Java, and I'd like to see it back on top, but right now I think the competition is better positioned and until the many initiatives going on (such as Loom) start to have a major impact on the ecosystem, it's no longer automatically my first choice.
While in general I agree with that philosophy, it doesn't really apply in this case.
When Orbit 1 was initially developed, Orleans was not open source, so the initial implementation was based off the Microsoft Research Whitepaper.
In our specific case, we had a lot of existing experience and services built on the JVM so adopting DotNet for Orleans (even if it had been available at the time) was not an option. The relative drop in priority for Orbit vs other projects was due to a need to dedicate more time to other parts of the platform.
As a large dev/publisher EA has a sizeable central technology group that develops everything from engines (Frostbite) to services (EA Digital Platform).
Ultimately I agree with the philosophy for smaller developers who are focused purely on making a game, but that's just not the reality at large companies and ultimately someone has to develop those services/engines.
Did you really make a throwaway just to make a comment that you knew would be downvoted, for both objective reasons as in Joe's response, and because you were unnecessarily rude?
If there's something you want to say that will be downvoted, just say it and eat the downvotes.
I'm not saying I agree with "ThE DowNVoteS SaY Im RigHt", I'm saying own your actions.
Edit: And if you don't want to own it, think twice before posting.
However, while the single-threadedness is a hard requirement and behavior of the system, the rule that only one message is processed at a time is not.
In Orbit (and Orleans) the ability to process multiple messages at the same time is called reentrancy. it can be specified at the actor or method level usually.
So in your example, say your initial message kicks off a write that is going to take 30 seconds. You start the write and assuming it's async, the actor then suspends while it waits for that to complete. While the actor is suspended another message asking for the progress arrives and that message is reentrant, it can process that message and respond with the progress, then the actor suspends again and at some point another reentrant message arrives or the initial write finishes and the first message finally gets a response. If a none reentrant message is received it will queue in the mailbox until after the first one is completed.
So, with reentrancy you still get the single threaded guarantee but you effectively get interleaving of messages when the actor is suspended waiting for some other async task to complete. This means that if you have an actor with reentrant messages you have to make that code safe to run during any potential interleaving point in another message (for example an await in async C#).
Hopefully that made sense, Orleans has some docs about reentrancy here you might find useful: https://dotnet.github.io/orleans/docs/grains/reentrancy.html
Other actor frameworks (particularly ones that are not based on virtual actors) may have different guarantees and behaviors but from what I've seen there is always some equivalent.