1 Message Passing
Akka has four core Actor message modes: Tell, Ask, Forward, and PIPE.
- Ask: Sends a message to the Actor that returns a Future. When the Actor returns a response, the Future is returned. No messages are returned to the sender’s mailbox.
- Tell: Sends a message to the Actor. All responses sent to the sender() are returned to the Actor that sent the message.
- Forward: Forwards the received message to another Actor. All responses sent to sender() are returned to the sender of the original message.
- Pipe: Used to return the result of the Future to sender() or another Actor. If you are using Ask or working with a Future, using Pipe will return the result of the Future correctly.
2 Messages cannot be changed
Mutable messages may occasionally cause unspeakable bad things to a program at some point. Therefore, it is best to ensure that messages are immutable, not only by ensuring immutable references, but also by ensuring immutable types. Using the final keyword ensures immutable references, and using String instead of StringBuffer ensures immutable types. Because strings are immutable, the contents of a StringBuffer are appended.Whenever data needs to be shared between threads, the first consideration should be to define messages as immutable.
Ask message pattern
The Ask mode generates a Future that represents the response returned by the Actor. This is often used when ordinary objects outside actors communicate with actors. When you call Ask to make a request to an Actor, Akka actually creates a temporary Actor in the Actor system of the initiator. This temporary Actor is the sender() reference that the Actor receiving the request uses when it returns the response. When an Actor receives a message from an ASK request and returns a response, the temporary Actor uses the returned response to complete the Future.Because the sender() reference points to the path to the temporary Actor, Akka knows which message to use to complete the Future. The Ask mode requires that a timeout parameter be defined, and if the response is not returned within the time specified by the timeout parameter, the Future will return a failure. The Ask pattern looks simple, but it has hidden additional performance overhead.First, ask causes Akka to create a new temporary Actor under the /temp path. The temporary Actor waits for a response back from the Actor receiving the Ask message. Second, Future also has additional performance overhead. Ask creates the Future, which is done by the temporary Actor. This is not a lot of overhead, but if you need to perform ask very frequently, you still need to take this overhead into account. Ask is simple, but for performance reasons, using Tell is a more efficient solution.
Tell message mode
Tell is the simplest message schema. Tell is often thought of as a fire-and-forget messaging mechanism without specifying a sender; But in some clever ways, it can also be done with Tellrequest/reply
Style of messagingTell is a method of the ActorRef/ActorSelection class. It can take a response address as an argument, and the sender() in the Actor that receives the message is that response address. In Scala, by default, the sender is implicitly defined as the Actor that sends the message. If there is no sender(such as sending a request outside the Actor system), the response address is not set by default to any mailbox (called DeadLetters). There is no implicit definition or default argument in Java, so you must provide the sender. If you do not want to specify any particular sender as the response address, you should write as follows:
- Send messages from within an Actor, using self(). Such as:
actor.tell(message,self())
- Initiate messages from outside the Actor system, using noSender(). Such as:
actor.tell(message,ActorRef.noSender())
In contrast to ASK, Tell is used to process the response
We can store some context information in the Actor in a map and send the map key together in a message. Then, when a message with the same key returns, you can restore the context and finish processing the message. This allows us to use ask-pattern-like semantics while avoiding the additional performance overhead of Asking.At first glance, this approach may seem to have a higher performance overhead than when using Ask, but it eliminates timeouts and the problem of creating additional actors when using Ask when you combine many actors. This allows us to control where the timeout occurs. Since tell does not need to provide a timeout parameter, we usually want to generate a timeout at some point in time.
Forward message pattern
Tell is semantically used to send a message to another Actor and to set the response address to the current Actor. The Forward does not. The original sender remains the same, but a new recipient is added. When a message is passed by Forward, the response address is the sender of the original message.
Pipe
Sometimes a Future in an Actor needs to be returned to the request sender. Sender () is a method, so to access sender() in the Future’s callback, we must store a reference to sender() :
final ActorRef senderRef = sender();
future.map(x -> {senderRef.tell(x,ActorRef.noSender())});
Copy the code
Future callbacks (such as the map above) are executed in another thread, so the correct value may not be accessible via sender(). That’s why you need to store the sender(). But the reason is not clear. For example, I was initially wondering why I didn’t write the sender() directly to the map function instead of using the reference stored above. By using Pipe mode, you can avoid the above confusion. The Pipe takes a Future result and returns the Future result to sender().
pipe(future,system.dispatcher()).to(sender());
Copy the code
The pipe receives the result of the Future as an argument and passes it to the supplied Actor reference. Because the sender() here executes on the current thread, you can call sender() directly. You don’t have to store a sender() reference like you did before.
reference
Akka Introduction and Practice — Chapter 3 Messaging
Attention public number: Data craftsman reply to Akka to get “Akka Introduction and Practice” book
Follow public accountData craftsman notes
, focus on big data field offline, real-time technology dry goods regular sharing! Personal websitewww.lllpan.top