He-Pin
commented
7 years ago Justin du Coeur, AKA Mark Waks @jducoeur 4月 17 23:48 @andrewmed Yeah, I usually say that Akka's purpose (that is Plain Old Akka, not Akka Streams) is to help you cope with the intersection of State plus Scale. It is helpful when you need to manage asynchronous access to non-trivial amounts of in-memory State, and invaluable when that State is more than can easily fit into a single node's memory. But outside of that, there are usually better ways to solve the problem. And note that Requester is mainly about making it easier to manage multi-Actor workflows. A typical Akka Actor has some amount of State itself -- I usually regard it as best practice for an Actor to have precisely one var, which contains an immutable data structure, and each message to the Actor potentially evolves that data structure to a new state. The issue Requester is addressing is the problem that ask(), the built-in mechanism for sending a message and receiving an answer, violates Akka's core invariant that there must never be multi-threaded access to that state; Requester wraps ask() in something that preserves that invariant.
@andrewmed I'm not entirely clear what you mean by "combining Actors" here. It's a simple parent/child tree, always -- a given Actor can have any number of children, and if the parent dies, it takes all the children with it. Actors specifically do not combine in FPish ways. (At least, not yet -- the new Akka Typed system should make more things possible, but folks are still puzzling over the implications.) As for your question, plain and simply, you should never, ever, block inside of an Actor unless absolutely required to do so by an external API. (And you need to adjust your architecture around that if so.) That's a pretty hard invariant of using Akka successfully -- blocking will eventually lead to disaster as you scale up. So your option (2) is a non-starter. OTOH, maintaining state is pretty much the entire point of Actors. Indeed, the Requester library basically exists for the sort of situation you're describing, where you want to perform a for-comprehension calculation that calls out to another Actor as part of it. You may want to look into that. All that said -- Akka's a relatively heavyweight solution for the sort of problem you seem to be describing. I'm a heavy Akka enthusiast, but from the sound of what you're saying I probably wouldn't reach for Akka to deal with this sort of AST-traversal problem, unless it was so enormous that it needed to be distributed across a cluster...