Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Actor system for the JVM developed by Electronic Arts

orbit.cloud

Post reply on HN
Print view View original

71–80 of 95 posts

Re: Actor system for the JVM developed by Electronic Arts

#71

Post by throwawaymaths »

spinningslate wrote: post #61
throwawaymaths wrote: post #38

Earlier quoted context omitted.

Just to be a bit pedantic (but important), Erlang is not an actor system. It's a system designed for fault tolerance and definable failure domains. Concurrency fell out of those requirements and it just happens to vaguely look like an actor system if you squint hard enough. I don't believe theories of actor systems played into the design of Erlang. Perhaps some of the blame belongs on the creators of Erlang for kind…

Fair point: Erlang wasn't designed as an Actor system. But you don't have to squint that hard to see the similarities. Again quoting wikipedia [0]: > An actor is a computational entity that, in response to a message it receives, can concurrently: send a finite number of messages to other actors; create a finite number of new actors; designate the behavior to be used for the next message it receives. > There is no ass…

No but also key to the definition of the actor system is that those are the only things they are allowed to do. Also, there's strange stuff like naming processes for service discovery, and iirc something is wrong with the way that Erlang does selective receives that disqualifies it from being an actor system, and ultimately more modern Erlang things like ets tables and sharing memory with nifs.

Point is all of these deviations from actor system were choices made by the Erlang team in the name of pragmatism. They all exist because there was a use case and the first teams using Erlang needed them for something real; that Erlang is not an actor system is important, because it's a highly pragmatic system -- not one that is based in theory.

Re: Actor system for the JVM developed by Electronic Arts

#72

Post by activitypea »

yashap wrote: post #22
gentleman11 wrote: post #3

> 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?

Actors 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…

Excellent description of the actor model, thank you!

Re: Actor system for the JVM developed by Electronic Arts

#73

Post by [deleted] »

throwawaymaths wrote: post #38
spinningslate wrote: post #32

Earlier quoted context omitted.

> those messages go into the actor’s mailbox, and then the actor processes them synchronously Not trying to be pedantic, but that's technically not true of the Actor formalism [0]. Quoting wikipedia: > an actor can designate the behavior to be used to process the next message, and then in fact begin processing another message M2 before it has finished processing M1. Available implementations (such as Erlang, Akka, Po…

Just to be a bit pedantic (but important), Erlang is not an actor system. It's a system designed for fault tolerance and definable failure domains. Concurrency fell out of those requirements and it just happens to vaguely look like an actor system if you squint hard enough. I don't believe theories of actor systems played into the design of Erlang. Perhaps some of the blame belongs on the creators of Erlang for kind…

[deleted]

Re: Actor system for the JVM developed by Electronic Arts

#74

Post by foob20220428 »

JoeHegarty wrote: post #70

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…

> "It is heavily inspired by the Microsoft Orleans project."

It's always better to focus on delivering the game rather than trying to make an own engine...

Re: Actor system for the JVM developed by Electronic Arts

#75

Post by JoeHegarty »

foob20220428 wrote: post #74
JoeHegarty wrote: post #70

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…

> "It is heavily inspired by the Microsoft Orleans project." It's always better to focus on delivering the game rather than trying to make an own engine...

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.

Re: Actor system for the JVM developed by Electronic Arts

#76

Post by ackfoobar »

ackfoobar wrote: post #49
bcrosby95 wrote: post #44

Earlier quoted context omitted.

I'm curious what you see as so different in an actor vs a queue with workers. An actor's mailbox effectively acts as a queue. Is it the supporting structure surrounding an actor focused library/language? Lots of person-hours have gone into making them to work well. Some home grown queue + pool of threads working off that queue... not so much.

You're exactly right. Some examples: - Some common patterns. E.g. actor hierachy and supervision, circuit breaker. - Persistence. The actor persists its state (changes) and can wake up from a sleep. - Clustering. The actor can live in another node, and you interact with it using the same API.

Well I misread and couldn't edit now.

What I meant is that you can launch a co/go-routine and have a channel that only it can read. That is like 70% the power of having an actor system.

---

> an actor vs a queue with workers

See the sibling comment.

TLDR: Actors each has their own queue. The orderings in each queue are independent. This can help with parallelization if it fits the shape of the problem.

Re: Actor system for the JVM developed by Electronic Arts

#77

Post by galaxyLogic »

spinningslate wrote: post #61
throwawaymaths wrote: post #38

Earlier quoted context omitted.

Just to be a bit pedantic (but important), Erlang is not an actor system. It's a system designed for fault tolerance and definable failure domains. Concurrency fell out of those requirements and it just happens to vaguely look like an actor system if you squint hard enough. I don't believe theories of actor systems played into the design of Erlang. Perhaps some of the blame belongs on the creators of Erlang for kind…

Fair point: Erlang wasn't designed as an Actor system. But you don't have to squint that hard to see the similarities. Again quoting wikipedia [0]: > An actor is a computational entity that, in response to a message it receives, can concurrently: send a finite number of messages to other actors; create a finite number of new actors; designate the behavior to be used for the next message it receives. > There is no ass…

> designate the behavior to be used for the next message it receives.

I think that is the key insight of actor-systems.

Actors don't have state. But they can calculate their replacement based on their immutable data. Thus the way an actor at a given address evolves is described by the functions that calculate the successor actors.

Thus you get Pure Functional Programming implemented on top of a fabric of distributed evolving entities. You can understand the behavior and evolution of such a system as a composition of function-calls, where functions always produce the same result for the same arguments.

Re: Actor system for the JVM developed by Electronic Arts

#78

Post by toast0 »

throwawaymaths wrote: post #71
spinningslate wrote: post #61

Earlier quoted context omitted.

Fair point: Erlang wasn't designed as an Actor system. But you don't have to squint that hard to see the similarities. Again quoting wikipedia [0]: > An actor is a computational entity that, in response to a message it receives, can concurrently: send a finite number of messages to other actors; create a finite number of new actors; designate the behavior to be used for the next message it receives. > There is no ass…

No but also key to the definition of the actor system is that those are the only things they are allowed to do. Also, there's strange stuff like naming processes for service discovery, and iirc something is wrong with the way that Erlang does selective receives that disqualifies it from being an actor system, and ultimately more modern Erlang things like ets tables and sharing memory with nifs. Point is all of these…

> Also, there's strange stuff like naming processes for service discovery, and iirc something is wrong with the way that Erlang does selective receives that disqualifies it from being an actor system, and ultimately more modern Erlang things like ets tables and sharing memory with nifs.

Ets tables are observationally equivalent to an Erlang process per table and sending it a message for each function call. It's not actually implemented that way, but I don't think that is grounds to disqualify it. I don't remember enough details about the naming process, but I think that might be similar; you could send a message to a naming process to set and lookup the names (although you'd have a bit of trouble finding out what the process id of the naming process is, wouldn't you?), it's just not very pragmatic.

Nifs certainly have the potential to break the model of course. I'd think selective receive should be fine too, it's equivalent to reading (or peeking) and saving messages until a matching message is received, processing that message, then processing future messages from the saved queue. It's just implemented in a more pragmatic way.

If immutability is important, then the process dictionary means Erlang doesn't qualify, but again, it's pragmatic.

I'd rather have a pragmatic almost actor system than a dogmatic Actor system that's hard to use.

Re: Actor system for the JVM developed by Electronic Arts

#79

Post by layer8 »

yashap wrote: post #22
gentleman11 wrote: post #3

> 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?

Actors 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…

I’m curious about the following: Suppose you have an actor that is tasked to perform a long-running operation (enacted by a specific message sent to the actor). Now suppose you want to know how far the actor has already progressed with the operation, or possibly you want to pause or stop/abort the operation – basically a monitoring and controlling interface. Would that be out of scope for the actor model? Polling the progress or gracefully stopping the operation would seem to require some asynchronous responsiveness from the actor. Is that something that is commonly supported by actor frameworks? If so, how does that work? Is that a gray area where the concrete actor implementation has to deal with concurrency after all, e.g. special callback routines that will be invoked concurrently to the main operation?

Re: Actor system for the JVM developed by Electronic Arts

#80

Post by Shared404 »

foob20220428 wrote: post #74
JoeHegarty wrote: post #70

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…

> "It is heavily inspired by the Microsoft Orleans project." It's always better to focus on delivering the game rather than trying to make an own engine...

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.

Post reply on HN