When working with Scala Akka, we still think about blocking IO, and try to avoid it with patterns, I feel it makes no difference from using threads. Implicitly async IO is a huge differentiator, Erlang and Go provide it at language level, while Scala Akka does not. I feel Scala Akka is not real actor model.
There's a popular blog post Don't use Actors for concurrency, but it's not really a problem of actor model, it's purely a problem of Akka.
Akka implements the Actor Model as specified by Carl Hewitt et al in 1973: an actor can upon reception of a message
send a finite number of messages to actors it knows
create a finite number of actors
determine the behavior to be applied to the next message
Nowhere does this say anything about how exactly I/O is supposed to be handled. Translating blocking method calls into actor-suspending method calls automatically is on the other hand a violation of the model: actors only act upon messages, nothing else, and declaring some arbitrary method calls to prevent that from happening for some (possibly unbounded) time is not part of the model.
Akka provides IO facilities for network operations that are presented in an Actor Model fashion by exposing an ActorRef that commands can be sent to and results can be received from. Akka Streams includes asynchronous consumption and production of data from and to I/O channels.
I hope this explains why my overall answer is that the premise of the question is flawed.
The premise of your question is inaccurate
("...Scala Akka does not."). From the akka documentation:
Actors give you:
Simple and high-level abstractions for concurrency and parallelism.
Asynchronous, non-blocking and highly performant event-driven
programming model. Very lightweight event-driven processes (several
million actors per GB of heap memory).
A basic example of asynchronous message passing to an Actor:
val actorSystem = ActorSystem()
val actorRef = actorSystem actorOf Props[SomeActor]
val message = ??? //some message value
actorRef ! message //asynchronous message passing
In fact, akka exceeds the original Actor Model specification with the ability to lookup Actors by name.
For IO specifically, akka offers many non-blocking solutions:
TCP
HTTP
Streaming File IO
Granted, Scala the language does not have an embedded Actor Model. But it provides Futures and parallel collections for concurrent computation.
The gist of the blog you quoted was that Futures are much better for concurrent computation (which I agree with), while Actors are for maintaining state. It wasn't claiming that Actors are incapable of concurrency.
Plus, akka is not just Actors. There are Agents, finite state machines, akka streams (implementing the reactive manifesto), and the akka-http library.
Related
I've made my research about Akka Framework,
And I would like to know ;
Is it possible to give a priority to a specific actor?
I mean - actors are working while getting a "let" message from the queue,
Is there an option to let an actor work even when it's not his turn yet to work?
Effectively, yes.
One of the parts of your Actor configuration is which Dispatcher those actors will use. A dispatcher is what connects the actor to the actual threads that will execute the work. (Dispatchers default to ForkJoinPools, but can also be dedicated thread pools or even threads dedicated to a specific actor.)
So the typical way you give an Actor "priority" is to give it a dedicated dispatcher, and thereby dedicated threads. For example, Akka itself does this for its internal messages: they run on a dedicated dispatcher so that even you deploy a bunch of poorly written actors that block the threads, Akka itself can still function.
I put "priority" in quotes, because you aren't guaranteeing a specific order of processing. (There are other ways to do that, but not across Actors.) But you are solving the case where you want specific actors to always have a greater access to resources and/or specific actors to get executed promptly.
(In theory, you could take this even further and create a ThreadPoolExecutor with higher priority threads, and then create a Dispatcher based on that ThreadPoolExecutor. That would truly give OS-level priority to an Actor, but that would only be likely relevant in very unusual circumstances.)
EDIT TO RESPOND TO "do mailboxes and dispatchers are the same" [sic]?
No. Each actor has a mailbox. So sometimes we talk about the behavior of mailboxes when discussing the behavior of actors, as the behavior of the mailbox governs the ordering of the actor's message processing.
But dispatchers are a distinct concept. Actors have a dispatcher, but it is many to one. (i.e. each Actor has one mailbox, but there may be many actors associated with a single dispatcher.)
For example, a real world situation might be:
System actors are processed by the internal dispatcher. To quote the docs "To protect the internal Actors that are spawned by the various Akka modules, a separate internal dispatcher is used by default." i.e. no matter how badly screwed up your own code might be, you can't screw up the heartbeat processing and other system messages because they are running on their own dispatcher, and thus their own threads.
Most actors (millions of them perhaps) are processed by the default dispatcher. Huge numbers of actors, as long as they are well behaved, can be handled with a tiny number of threads. So they might all be configured to use the default dispatcher.
Badly behaved actors (such as those that block) might be configured to be processed by a dedicated "blocking" dispatcher. By isolating blocking dispatchers into a separate dispatcher they don't impact the response time of the default dispatcher.
Although I don't see this often, you might also have a dispatcher for extremely response time sensitive actors that gives them a dedicated thread pool. Or even a "pinned" dispatcher that gives an actor a dedicated thread.
As I mentioned this isn't really "priority", this is "dedicated resources". Because one of the critical aspects of actors is that the are location independent. So if Actor A is on Node A, and Actor B is on Node B, I can't guarantee that Actor A will ALWAYS act first. Because doing so would involve an ASTRONOMINCAL amount of overhead between nodes. All I can reasonably do is give Actor A dedicated resources so that I know that Actor A should always be able to act quickly.
Note that this is what the internal dispatcher does as well. We don't guarantee that heartbeat messages are always processed first, but we do make sure that there are always threads available to process system messages, even if some bad user code has blocked the default dispatcher.
I'm going through this tutorial: https://doc.akka.io/docs/akka/current/typed/guide/tutorial_3.html and don't quite understand when the at-most-once message semantics is preferable, since although we get performance gains, we lose resiliency of messages. It looks like the justification for this trade-off is explained here:
We only want to report success once the order has been actually fully processed and persisted. The only entity that can report success is the application itself, since only it has any understanding of the domain guarantees required. No generalized framework can figure out the specifics of a particular domain and what is considered a success in that domain.
In this particular example, we only want to signal success after a successful database write, where the database acknowledged that the order is now safely stored. For these reasons Akka lifts the responsibilities of guarantees to the application itself, i.e. you have to implement them yourself with the tools that Akka provides. This gives you full control of the guarantees that you want to provide. Now, let’s consider the message ordering that Akka provides to make it easy to reason about application logic.
, but I don't quite understand what it means. Any help in understanding this or some other considerations for this decision is appreciated.
I read this thread RPC semantics what exactly is the purpose which seemed to offer a clear definition of the use cases of at-most-once semantics with payment submission as the example of something you wouldn't want to duplicate. But from the quoted paragraph above, it sounds like the messages would be sent out into the ether with no regard for an ack that confirms success or failure of message delivery. I'm wondering if both descriptions of at-most-once semantics is correct to their respective domains, how to get the behavior in the other stackoverflow thread with an acknowledgement from akka.
All anything that doesn't know about the domain can offer with at-least or exactly-once delivery is that the message has been delivered (a guarantee that the message has been processed is also possible and practical in at least some (but not all) scenarios). This is fine if it's what you want, but conflating this with something higher level (like "order has been durably recorded") is virtually certain to lead to essentially impossible to debug bugs down the road.
At-least-once is quite easy to accomplish in Akka by having messages include a field containing an ActorRef to which to send an ack (or other response) and having the sender resend unacked messages (because it's eminently possible for the ack to get dropped, these retries are what leads to at-least-once). The ask pattern (included with Akka) provides this at a high level: in Akka Typed this is done by specifying an adapter function so that when actor A asks actor B, B can send a message in its protocol and A gets a message in its protocol (avoiding a chicken-and-egg problem); if no response is received in a specified timeframe, the adapter causes a failure message to be sent to actor A which (for at-least-once semantics would dictate that A eventually retry the message). The critical thing to remember is that it's actor B (or its designee: e.g. if B farms the work out to a worker actor, that worker actor can send the acknowledgement to A) that decides whether and when to respond, not Akka.
If doing at-least-once, it's very useful to design the messaging protocol around idempotence: a retry of a successful message doesn't result in a side effect beyond an ack. Idempotence plus at-least-once has been referred to as "effectively-once" and it's a lot easier to implement and lighter-weight than exactly-once.
Akka's docs on interaction patterns describe various messaging patterns in Akka, with a discussion of advantages and disadvantages. Fairly recently, especially when using Akka Cluster and Akka Persistence, there is a fairly heavyweight implementation of reliable delivery: in the maximum reliability mode (using Akka Persistence), because each message sent in this way is persisted to a datastore (e.g. local disk, or cassandra, or...), the latency for a message send is severely increased.
I have read that:
Akka ensures that each instance of an actor runs in its own lightweight thread and its messages are processed one at a time.
If this is the case that AKKA actors processes its messages sequentially then how AKKA provides concurrency for a single Actor.
Actors are independent agents of computation, each one is executed strictly sequentially but many actors can be executed concurrently. You can view an Actor as a Thread that costs only about 0.1% of what a normal thread costs and that also has an address to which you can send messages—you can of course manage a queue in your own Thread and use that for message passing but you’d have to implement all that yourself.
If Akka—or the Actor Model—stopped here, then it would indeed not be very useful. The trick is that giving stable addresses (ActorRef) to the Actors enables them to communicate even across machine boundaries, over a network, in a cluster. It also allows them to be supervised for principled failure handling—when a normal Thread throws an exception it simply terminates and nothing is done to fix it.
It is this whole package of encapsulation (provided by hiding everything behind ActorRef), message-based communication that is location transparent, and support for failure handling that makes the Actor Model a perfect fit for expressing distributed systems. And today there is a distributed system of many CPU cores within even the smallest devices.
The Typesafe whitepaper (v5) states:
"In different scenarios, actors may be an alternative to: a thread; a Java EE session bean; ..."
I don't understand how an actor is an alternative to a session bean, because they work completely differently: an actor is called serially by passing messages to it and it processes the messages one at a time in the order in which they are sent. That means the running of any business logic inside the actor is synchronised. Session beans on the other hand are pooled - there is a number of them and multiple threads can run the same business logic at any time meaning that the logic is run concurrently.
Can anyone clear up my misunderstanding of this statement?
You can pool Actors (children) or behind Akka Routers (also technically children), so that way you can tune "concurrency".
Too much ejb concurrency can often be a cause of various lock contention and performance degradation.
Meanwhile akka is aimed at async processing and nio. This approach benefits most of all when number of threads is near the number of CPU cores.
Note that akka doesn't enforce exactly one processing thread. See e.g. Akka control threadpool threads
I do have Java application with lot of threads and thread pools. Can we use AKKA to replace the threads and thread pools?
It depends on what your threads are doing. Are they doing blocking IO or taking locks and sharing mutable data between themselves? If so akka might not be a great fit as actors generally should avoid blocking for io or locks. On the other hand, if the threads do isolated non-blocking work, and can communicate via message passing, akka is probably a good fit.
Yes, you absolutely can. Be careful about the above poster's response. That isn't entirely accurate. Actors can do blocking I/O. You just use child actors to represent each blocking connection. The newbie mistake would be to treat actors the same way you would treat a thread... in which case, the poster above's answer would be right. But, if you pass off the blocking to a lower actor and use an ad-hoc actor each time, you'll never have to block the main throughput.
But, forgive me. I have gone off track. In short, yes, you can. But keep in mind there will be a learning curve. Actors programming is a different paradigm and it needs to be handled a bit differently.
However, programming concurrency with actors is leagues easier than with threads and locking (literally). Just make your app reactive instead of time-based and many concurrency concerns just stop existing.
Check out the AKKA docs on their site. They are very thorough. Also the books Akka concurrency and effective Akka. Just keep 'em on the desk as a reference.