10 ms·
Actor system for the JVM developed by Electronic Arts
- slantedview 4y agoI wonder what problems this project aimed to solve that Akka didn't already solve.
- lichtenberger 4y agoDoes anyone know how it compares to Akka?
- ackfoobar 4y agoAt a glance: Sending a message is simply a function call. Whereas in Akka it's the ask pattern where you have to manually reify the function call parameters into a case class. If you want to wait in processing a message in Akka, you either have to juggle the message queue with stashing or block a thread. In Orbit it is a `suspend` fun.
- joostdevries 4y agoIt's an interesting idea; not having to stash messages in the actor implementation when doing an async call. I did a little experiment what that could look like using Akka and kotlin suspend functions https://github.com/joost-de-vries/akka-kotlin https://github.com/joost-de-vries/akka-kotlin
- gentleman11 4y ago> Orbit is a framework to write distributed systems using virtual actors on the JVM. A virtual actor is an object that interacts with the world using asynchronous messages. Could anybody elaborate on this? How does an actor differ from an object that uses promises to talk to a server?
- mjburgess 4y agoYip, that's basically just an actor. When people talk about actor-based languages or frameworks however, theyre suggesting syntax primitives which help express this more naturally. The simple pitch is: OO where objects could be on any machine.
- pdpi 4y agoObjects, actors, and (micro-)services are basically the exact same concept at different scales.
- spinningslate 4y agoTo some approximation. The Actor Model formalism [0] requires certain properties, notably: 1. Communication solely by asynchronous message passing 2. A mailbox per actor that means the reception of messages and the processing of them is decoupled (i.e. an actor can receive new messages even when processing a previously-received message). The OO model in general supports that paradigm. Pretty much all mainstream OO languages are synchronous by default though. Call a method and the caller is suspended until the method returns. Multiple clients can call methods on the same object concurrently, but doing that safely requires some form of locking/protection to be implemented in the target object. Stated alternatively: threads in mainstream OO languages run "across" objects, whereas each actor has its own thread in the Actor model. There are certainly similarities - in the sense that both actors and objects encapsulate state, with reading/writing occurring through well-defined interfaces (messages and methods respectively). But the threading model is quite different - it's not just a matter of scale. [0] https://en.wikipedia.org/wiki/Actor_model https://en.wikipedia.org/wiki/Actor_model EDIT: corrected grammar & formatting.
- usrusr 4y agoThanks for making me feel old by not including agents in the list. Those seem even more similar to actors. At least until someone mentions BDI, then it's suddenly an entirely different universe.
- asadawadia 4y agoactor model has nothing to do with promises
- beardedetim 4y agoUsually the difference is the "mailbox" an actor has, making the difference more about the level you're calling an actor more than the differences in any code you might write.
- diroussel 4y agoIt’s not the same as async objects. There are differences between different score systems. But have a look at Elang and Akka for example. But I’m actor systems the actors maybe more stateful that you typical object and be location transparent. Communication between actors does require knowledge of if another actor is in process or remote. Also the actor supervising model is a completely different way of recovering from errors than in OO systems.
- whoisthemachine 4y agoA promise is a specific class of an actor - https://en.wikipedia.org/wiki/Futures_and_promises#Semantics_of_futures_in_the_actor_model https://en.wikipedia.org/wiki/Futures_and_promises#Semantics...
- xeromal 4y agoThis is based on a popular and fundamental computer science paradigm. If you're not familiar with it, it's a good read. https://en.wikipedia.org/wiki/Actor_model https://en.wikipedia.org/wiki/Actor_model
- yashap 4y agoActors are useful for keeping code clean/understandable/correct when dealing with heavy concurrency AND lots of mutable state. Actors are like objects, but the only way to interact with them is sending them a message - you can’t directly access their properties, call their methods, etc. Messages are bits of immutable data sent between actors asynchronously, but those messages go into the actor’s mailbox, and then the actor processes them synchronously, one at a time. You can get parallelism by adding more actors of the same type (10 actors of the same type lets you process up to 10 messages concurrently). Because actors are totally synchronous INTERNALLY, and nobody can directly access their internal state, it’s fine for them to have mutable internal state, with no locking/synchronization needed, and much easier to reason about than mutable state normally is in highly concurrent applications. With that being said, the actor model has a lot of inherent complexity. If you don’t need it, don’t use it. But if you really do need lots of concurrency and lots of mutable state, it’s often a great choice. They’re also good for distributed systems. Actors only communicate by sending messages to other actors, but it doesn’t really matter if that message is sent in memory to an actor in the same process, or over the network to an actor on a different machine. So you can take a single actor system and split it across many machines pretty easily. Generally the actor framework you’re using will handle delivering messages over the network, ensuring there’s the right number of actors running across all nodes combined, etc.
- dragonwriter 4y ago> Actors are like objects, but the only way to interact with them is sending a message - you can’t access their properties, call their methods, etc. While the implementation in many popular, e.g. C++ and family descended from it, languages muddies the waters, basically methods in OO are a convenient way to define handlers for messages sent to objects, and in pure OO you also can't interact with objects except by sending messages to them. The difference between the basic OO model and the actor model is that OO message sends are synchronous request/response and actor model message sends are asynchronous fire-and-forget.
- yashap 4y agoAgreed, although it’s not always fire-and-forget (i.e. send a message and don’t wait for a response). Actors generally do support request/response style messaging, but it’s always async - it’s really only synchronous request/response communication that’s not allowed.
- ctvo 4y agoThis is a very broad question. I would start with understanding the concept of actors. You'll end up reading about Erlang, Akka, etc. Then what's a virtual actor and how does it differ? You'll eventually end up at the Orleans paper from MSFT research: https://www.microsoft.com/en-us/research/publication/orleans-distributed-virtual-actors-for-programmability-and-scalability/ https://www.microsoft.com/en-us/research/publication/orleans... It really has nothing to do with promises (as used colloquially) and is a way to design large distributed systems using message passing and localized state that's persisted.
- dordoka 4y agoIt implements the actor model paradigm. Check this video https://www.youtube.com/watch?v=7erJ1DV_Tlo https://www.youtube.com/watch?v=7erJ1DV_Tlo
- birdyrooster 4y agoHighly suggested watch the creator of the actor model explain to some skeptics. https://youtu.be/7erJ1DV_Tlo https://youtu.be/7erJ1DV_Tlo
- shartte 4y agoIt looks interesting, but seems to be dead. The repository has virtually no activity since september 2020.
- ackfoobar 4y agoOh well, looks like it has the same fate as protoactor-kotlin.
- newobj 4y ago“Exactly one” is a hard concept to get right. How do they ensure that exactly one instance of an actor is alive at once, without sacrificing latency of actor start and/or while tolerating network partitions?
- ackfoobar 4y agohttps://proto.actor/docs/cluster-partitions/#multiple-activations https://proto.actor/docs/cluster-partitions/#multiple-activa... > This can be prevented by persisting state in a database with some form of CAS operations, e.g. Couchbase.
- mirekrusin 4y agoThat's still "at most one" – ie. even though state of database itself is "exactly one" (...can "hold the lock") – the fact that actor thread is remote, it means it can be partitioned/starve the rest of the system. "Exactly once" can be achieved with "at least once" + _local_, reliable state where you can resolve/ignore duplicates. But if that "local" state is actually "remote" – well, then you loose this guarantee (because you can be arbitrarily partitioned from that state so you're in square one again).
- Pxtl 4y agoI assume EA didn't make this just for funsies. What do they use it for?
- baud147258 4y agofrom the article on its release: http://blog.bioware.com/2015/03/30/launching-into-orbit/ http://blog.bioware.com/2015/03/30/launching-into-orbit/ (HN thread: https://news.ycombinator.com/item?id=9300672 https://news.ycombinator.com/item?id=9300672) > The last-generation of Orbit powered some of the key technology behind the Dragon Age Keep and Dragon Age: Inquisition. Our plans for the next-generation framework are even more ambitious. So at least it was used for some of Bioware's games
- deleted 4y ago[deleted]
- g051051 4y agoIt'd be a lot more interesting if it wasn't in Kotlin.
- qlm 4y agoWhy does that matter? Kotlin has interop with other JVM languages.
- guipsp 4y agoIt does seem that some of the more interesting features require kotlin, which makes calling it an actor system for the jvm a bit meh, in my opinion.
- spacemanmatt 4y agoYou might be a candidate for Vert.x
- michaelcampbell 4y agoTo me it makes it that much more interesting, but reasonable people can disagree.
- wiseowise 4y agoWhy?
- ackfoobar 4y agopast: https://news.ycombinator.com/item?id=9300672 https://news.ycombinator.com/item?id=9300672
- btbuildem 4y agoI can't help but recoil from a "hello world" that pulls in an entire container ship of dependencies. Especially that we already have a perfectly good, battle-hardened, and relatively lightweight implementation of Actor model with Erlang / Elixir.
- capableweb 4y ago> I can't help but recoil from a "hello world" that pulls in an entire container ship of dependencies. Where do you see the list of dependencies? Seems to me to be the ones defined at https://github.com/orbit/orbit/blob/233956001f1206ccbfde72efb0eab8479761951e/build.gradle.kts#L14-L35 https://github.com/orbit/orbit/blob/233956001f1206ccbfde72ef..., is that correct? Doesn't look like "an entire container ship" but maybe the NPM madness have ruined me. > Especially that we already have a perfectly good, battle-hardened, and relatively lightweight implementation of Actor model with Erlang / Elixir. Yeah, if you're already using Erland or Elixir, why don't you go with that instead? This seems to be for the JVM, so one could assume that the ones who want to use this, is already invested heavily in the JVM ecosystem (which as far as I know, EA is when it comes to backend servers).
- dijit 4y agoOrbit is also the name of the always online DRM system that Ubisoft made many years ago. Fun fact, the tech that was developed to power Orbit forked and evolved along largely divergent paths to be Uplay and the framework on which the Division and Division 2 online backends were made. You can still see paths referencing Orbit in uplay, especially on the downloads: http://static3.cdn.ubi.com/orbit/launcher_installer/UbisoftGameLauncherInstaller.exe http://static3.cdn.ubi.com/orbit/launcher_installer/UbisoftG... Largely C++ on Windows.
- deleted 4y ago[deleted]
- tdstein 4y agoHow does this compare to Erlang / Elixir?
- the_arun 4y agoIs actor system same as event based systems or event driven architecture?
- chaostheory 4y agoIt’s an alternative to working with threads. You pass “work” as messages to “actors” instead of using locks on resources.
- klysm 4y agoActors are a more specific model of computation. Definitely related to event based systems but far more specific.
- sandGorgon 4y agoa very interesting counterpoint is Vert.x - https://vertx.io/docs/vertx-core/java/ https://vertx.io/docs/vertx-core/java/ Vert.x uses a concept called Verticles - which are like actors..with an external message bus. Which ends up being more practical if you start leveraging kafka, etc in the architecture.
- spacemanmatt 4y agoVert.x has grown on me fast! Verticles are the right combination of actors and good-old pragma. The community is healthy and helpful, too. I hope to stick with Vert.x for a long time even.
- voz_ 4y agoAh GC languages, a curse upon us.
- verst 4y agoThe OSS project I work on, Dapr (Distributed Application Runtime - an incubated CNCF project) implements the virtual actor pattern if anyone is interested. https://docs.dapr.io/developing-applications/building-blocks/actors/actors-overview/ https://docs.dapr.io/developing-applications/building-blocks... https://github.com/dapr/dapr https://github.com/dapr/dapr
- asabla 4y agoBeen digging my self deeper and deeper into Dapr, Orleans and similar for several years now. Super cool tech! so thank you for your contributions and future work on this.
- giancarlostoro 4y agoI found out about this one a few years back from a former (online) friend who worked on it (although I'm not entirely certain in his specific involvement, I want to say he was the lead developer initially though), his name is Joe Hegarty[0]. There was another implementation as well from him in TypeScript for Node.js called Ratatoskr[1]. As far as I've always known him, he always works on networking projects, I believe he worked on the Fable 3 networking for coop and several other games. I can't even imagine what he works on at EA now honestly. JoeH if you're reading this by chance: Just remember you were an inspiration back in the day (mid to late 2000s) to a lot of people who became developers and learned a ton from your work back then, myself included. To this day I remember asking you questions almost every day. Thank you for your efforts and your patience. [0] https://www.joeh.ca/ https://www.joeh.ca/ [1] https://github.com/ratatoskr/ratatoskr https://github.com/ratatoskr/ratatoskr
- JoeHegarty 4y agoThank you for your kind words. I do indeed still work on networking stuff.
- JoeHegarty 4y agoSo, 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.
- haolez 4y agoI'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.
- shaunxcode 4y agoDo you have an opinion about Project Loom?
- JoeHegarty 4y agoI 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.
- hestefisk 4y agoWhy would one pick this over Akka?
- mavam 4y agoI'd like to mention the native actor model implementation CAF, the C++ Actor Framework, and share some experiences. (Disclaimer: I've been developing on CAF in the past and have a good relationship with the creator.) CAF (1) provides native actors without an VM layer, (2) type-safe interfaces so that the compiler yells at you when a receiver cannot handle a message, and (3) transparent copy-on-write messaging so that you can still push stuff through pipelines and induce only copies only when a ref count is greater than one. In our telemetry engine VAST, we've been using CAF successfully for several years for building a distributed system that always has a saturated write path. CAF provides a credit-based streaming abstraction as well, so that you can have backpressure across a chain of actors, making burst-induced OOM issues a blast from the past. You also get all the other benefits of actors, like linking and monitoring, to achieve well-defined failure semantics: either be up and running or collectively fail, but still allowing for local recovery—except for segfaults, this is where "native" has a disadvantage over VM-based actor models. With CAF's network transparent runtime, a message ender doesn't need to know where receiver lives; the runtime either passes the message as COW pointer to the receiver or serializes it transparently. Other actor model runtimes support that as well, but I'm mentioning it because our experience showed that this is great value: we can can slice and dice our actors based on the deployment target, e.g., execute the application in one single process (e.g., for a beefy box) or wrap actors into single OS processes (e.g., when deploying on container auto-scalers). The deep integration with the C++ type system allowed us to define very stable RPC-like interfaces. We're currently designing a pub/sub layer as alternate access path, because users are interested in tapping into streaming feeds selectively. This is not easy, because request-response and pub/sub are two ends of a spectrum, but it turns out we can support nicely with CAF. Resources: - CAF: https://github.com/actor-framework/actor-framework https://github.com/actor-framework/actor-framework - VAST: https://tenzir.github.io/vast/docs/understand-vast/actor-model https://tenzir.github.io/vast/docs/understand-vast/actor-mod... (sorry for the incompleteness, we're in migration mode from the old docs, but this page is summarizing the benefits of CAF for us best) - Good general actor model background: http://dist-prog-book.com/chapter/3/message-passing.html#why-the-actor-model http://dist-prog-book.com/chapter/3/message-passing.html#why...
- tsss 4y agoI still don't get why you need actors. In all my years I've never come across some problem and thought "this would be a great use for actors". Is the kind of applications that I write simply not suited to it? Many other people here in the comments have mentioned how actors can be used to serialize access to mutable state. My applications almost never have mutable state, especially not non-local mutable state that would require locks, except maybe caches. All mutable data is generally in some kind of highly available database and too large to hold in memory anyway. Message queues (like in an actor's message box) can never be in memory or they would lose data when the application crashes. The reasoning in the book that you linked does not make sense to me. Any serious language nowadays has some kind of lightweight thread abstraction which you can spawn thousands or millions of without making a dent into system resources, so this is a non-issue. It goes on to say that > This alleviates the need for the programmer to reason about an entire system. Instead the programmer has a fixed set of concerns, meaning they can ensure behavioral correctness in isolation, rather than having to worry about an interaction they hadn’t anticipated occurring. which is just blatantly false. You can reason about a single actor, yes, but doing so is not helpful when you are interested in the correctness of the entire system. Since actor boundaries are an operational concern, they do not align with the domain logic. To understand the domain logic you always have to look at interactions of multiple actors (a single actor would be pointless) all with their own mutable state, all which can receive messages from anywhere at any time with no guarantees of timely reply to its own messages. A functional programming approach on the other hand is much easier to reason about with a well defined denotational semantics, no peer-to-peer interactions, no mutable state (generally) and composition of components that are aligned with domain boundaries and thus meaningful in isolation. > Without a lightweight process abstraction, users are often forced to write parts of concurrent applications in an event-driven style which obscures control flow, and increases the burden on the programmer. This is exactly the argument _against_ actors in my mind. Because actors communicate only through messages, they enjoy high decoupling but the price for this is horrible cohesion. Any domain logic that is spread across multiple actors will quickly become incomprehensible and unmaintainable. The same is true for event-driven microservices and a great deal of architectural work goes into making the microservices as large as possible to improve cohesion while making them as small as necessary to be independently scalable.