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

81–90 of 95 posts

Re: Actor system for the JVM developed by Electronic Arts

#81

Post by haolez »

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…

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.

Re: Actor system for the JVM developed by Electronic Arts

#82

Post by JoeHegarty »

layer8 wrote: post #79
yashap wrote: post #22

Earlier quoted context omitted.

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…

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#).

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.

Re: Actor system for the JVM developed by Electronic Arts

#83

Post by layer8 »

JoeHegarty wrote: post #82
layer8 wrote: post #79

Earlier quoted context omitted.

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…

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…

That makes sense, thanks for the explanation.

Re: Actor system for the JVM developed by Electronic Arts

#85

Post by helge9210 »

bcrosby95 wrote: post #44
lostcolony wrote: post #42

Earlier quoted context omitted.

>> 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. I kind of disagree with this. I mean, it's kind of correct, if you literally have a sequential problem with immutable state you're gaining nothing from it, but you're also losing nothing (you...will have one a…

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.

> so different in an actor vs a queue with workers

In short: different computational model -- Actor model vs. Communicating sequential processes.

This really helped me: https://youtu.be/7erJ1DV_Tlo

Edit: added link to video

Re: Actor system for the JVM developed by Electronic Arts

#86

Post by shaunxcode »

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…

Do you have an opinion about Project Loom?

Re: Actor system for the JVM developed by Electronic Arts

#87

Post by mavam »

I'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

- VAST: 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...

Re: Actor system for the JVM developed by Electronic Arts

#88

Post by imtringued »

ackfoobar wrote: post #76
ackfoobar wrote: post #49

Earlier quoted context omitted.

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 worker s 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.

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

You can also iterate over an array in parallel and only modify the current element and that is like 70% of the power of having an actor system.

"Structured concurrency is a programming paradigm aimed at improving the clarity, quality, and development time of a computer program by using a structured approach to concurrent programming." - Wikipedia

Re: Actor system for the JVM developed by Electronic Arts

#89

Post by pjmlp »

zo1 wrote: post #55
dragonwriter wrote: post #27

Earlier quoted context omitted.

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

So much this. This "actor model" thing as described by GP sounds like plain old OO and RPC with extra steps and also distributed. This may be a low-effort post on my part, but I'm 100% not impressed because it sounds like marketing fluff and an opportunity to rewrite native/built-in things using frameworks. Also justifying Yet Another Framework or tool hosted on an .IO domain (snarky I know) for promotions and endles…

Smalltalk is like this, and Objective-C by following on Smalltalk's design, had a great experience for writing distributed applications on NeXTSTEP.

Re: Actor system for the JVM developed by Electronic Arts

#90

Post by imtringued »

zo1 wrote: post #55
dragonwriter wrote: post #27

Earlier quoted context omitted.

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

So much this. This "actor model" thing as described by GP sounds like plain old OO and RPC with extra steps and also distributed. This may be a low-effort post on my part, but I'm 100% not impressed because it sounds like marketing fluff and an opportunity to rewrite native/built-in things using frameworks. Also justifying Yet Another Framework or tool hosted on an .IO domain (snarky I know) for promotions and endles…

I don't know what you mean by "rewrite native/built-in things using frameworks", the things you are talking about require using frameworks. You need a framework for RPC. You also need a framework for distributed shared memory.
Post reply on HN