book

Akka in Action, Second Edition

by Raymond Roestenburg, Rob Williams, Francisco Lopez Sancho, Robertus Bakker

August 2023

Intermediate to advanced

400 pages

11h 7m

English

Manning Publications

Read now

Unlock full access

prefaceacknowledgmentsabout this bookWho should read this bookHow this book is organized: A roadmapAbout the codeliveBook discussion forumabout the authorAuthors of the previous editionabout the cover illustration
1.1 What is Akka?1.2 Actors: A quick overview1.3 Two approaches to scaling: Setting up the example1.4 Traditional scaling1.4.1 Traditional scaling and durability: Moving everything to the database1.4.2 Traditional scaling and interactive use: Polling1.4.3 Traditional scaling: Transactions1.5 Scaling with Akka1.5.1 Scaling with Akka and durability: Sending and receiving messages1.5.2 Scaling with Akka and interactive use: Pushing messages1.5.3 Scaling with Akka and failure: Asynchronous decoupling1.5.4 The Akka approach: Sending and receiving messages1.6 Actors: One programming model to rule up and out1.6.1 An asynchronous model1.6.2 Actor operations1.7 Akka actors1.7.1 ActorSystem1.7.2 ActorRef, mailboxes, and actors1.7.3 Dispatchers1.7.4 Actors and the networkSummary
2.1 Printing money2.2 Starting to code2.2.1 The protocol of the actor2.2.2 Creating an application and instantiating the actor2.2.3 Sending messages2.2.4 Implementing the actor: Receiving messages2.2.5 Terminating the system2.2.6 The application2.2.7 The solution in Git2.2.8 Running the app2.3 Keeping state with a variable2.4 Keeping state with behaviors2.5 Scheduling a messageSummary
3.1 Simple parser example3.1.1 Coding the app3.1.2 Coding the guardian and spawning3.1.3 Sending messages back and forth: Adapting responses3.1.4 The protocol with the adapter’s message3.1.5 The adapter’s function3.1.6 Delegating3.1.7 A protocol with commands and responses as traits3.1.8 Coding the worker3.2 Asking and expecting a reply3.2.1 A simple question3.2.2 Coding the manager3.2.3 The protocols3.2.4 Asking3.2.5 Coding the worker3.2.6 Using context3.2.7 Ask signature3.3 Ask with a payloadSummary

4.1 Testing approaches4.2 Sync testing4.2.1 Effects4.2.2 More than one actor4.2.3 Testing the logs4.3 Async testing4.3.1 Using probes4.3.2 Fishing for messages4.3.3 Logging4.3.4 Log capturingSummary
5.1 What fault tolerance is (and what it isn’t)5.1.1 Plain old objects and exceptions5.1.2 Wrap it up and let it crash5.2 Actor lifecycle events: Signals5.3 Supervision strategies and signals5.3.1 Uneventful resuming5.3.2 Stopping and the PostStop signal5.3.3 Restart and the PreRestart signal5.3.4 Custom strategy5.4 Watching signals from an actor5.5 Back to the initial use case5.5.1 Supervisor hierarchy initial design5.5.2 Supervision hierarchy alternative designSummary
6.1 Discovery: The receptionist6.2 The built-in integration router pattern6.3 Balancing load using built-in routers6.3.1 Akka pool router6.3.2 Changing strategies6.3.3 Akka group router6.3.4 Consistent hashing strategy6.4 Implementing the router pattern using actors6.4.1 Content-based routing6.4.2 State-based routingSummary
7.1 Trying out Akka configuration7.1.1 Order7.1.2 Subtrees7.1.3 Substitutions7.1.4 Using defaults7.2 Akka configuration7.3 Multiple systems7.3.1 Lifting with Fallback7.4 Configuration in tests7.4.1 Lifting in testsSummary
8.1 On top of Akka Cluster8.2 Why use clustering?8.2.1 Cluster membership: Joining a cluster8.2.2 Minimal cluster example8.2.3 Starting the cluster8.2.4 Leaving the cluster8.2.5 Unreachable8.2.6 Downing a reachable node8.3 Akka Management and the Cluster HTTP extension8.3.1 Cluster subscriptions8.4 Clustered job processing8.4.1 In practice8.4.2 The code8.4.3 Work distribution in the master8.4.4 Starting the cluster8.5 Resilient job8.5.1 Serialization8.5.2 Testing is no differentSummary
9.1 Akka sharding and stateful systems9.1.1 The big picture9.1.2 An example: A shipping container9.1.3 The simplicity of the sharded entities9.1.4 Rebalancing configuration9.1.5 Passivation9.1.6 Remembering entities9.2 Persistence9.2.1 The ingredients9.2.2 Persistence combined with sharding: A persistent entity9.2.3 Available effects9.3 Customizing the persistent entity9.3.1 Failure9.3.2 Recovery9.3.3 Snapshotting9.3.4 Tagging9.3.5 A peek at serialization and schema evolution9.4 Running exampleSummary
10.1 Akka Streams10.1.1 Basic semantics10.1.2 Finite streams10.1.3 Source10.1.4 Flow10.1.5 Sink10.1.6 Blueprint10.1.7 Materialization10.1.8 Infinite streams10.2 Akka Persistence Query10.2.1 Where the rubber meets the road10.3 Projections10.3.1 Reading10.3.2 Writing10.3.3 Putting everything together10.3.4 The ShardedDaemonProcess10.3.5 Back to the SPContainer projection10.3.6 All the main parts10.4 Projections in actionSummary
11.1 Akka HTTP11.1.1 Akka HTTP servers11.1.2 The path11.1.3 Directives11.1.4 Route directives11.1.5 Marshalling and unmarshalling11.1.6 Akka HTTP communicating with actors11.2 Akka gRPC11.2.1 The Protocol Buffers side11.2.2 The RPC side11.2.3 The plugin and the .proto file11.2.4 Akka gRPC in action11.2.5 Running the service11.2.6 Akka gRPC with an actor11.2.7 Running the exampleSummary
12.1 The actors12.1.1 The wallet12.1.2 The market12.1.3 The bet12.2 The ports12.2.1 The marketSummary
13.1 Akka Cluster Bootstrap13.1.1 Clustering in local13.1.2 Cluster in action13.2 Clustering with the Kubernetes API13.2.1 Creating the Docker image13.2.2 Kubernetes deployment13.2.3 Optional: Setting Java options13.2.4 Kubernetes role and role binding13.2.5 Service account13.3 Split Brain Resolver13.3.1 An unreachable problem13.3.2 SBR strategies13.4 Cluster singletonsSummary
14.1 Alpakka Kafka14.1.1 Consuming from Kafka in action14.1.2 Detecting consumer failures14.1.3 Auto-commit14.1.4 Committable sources14.2 Pushing to Kafka14.2.1 At-most-once delivery guarantee14.2.2 At-least-once delivery guarantee14.3 Effectively-once delivery14.4 Alpakka CSV14.4.1 Mapping by column14.4.2 Reading and writing with FileIOSummary
15.1 Projections15.1.1 Database projection15.1.2 Kafka projection15.1.3 The betting-house entry point15.2 Configuration15.2.1 Persistence15.2.2 Cluster local15.2.3 Cluster Kubernetes15.2.4 Services, sharding, and projections15.3 Deployment15.3.1 Running local15.3.2 Running in KubernetesSummary
16.1 Processing elements through services16.1.1 CPU-bounded services16.1.2 Non-CPU bounded services16.2 Connecting to an actor16.3 Dealing with exceptions16.3.1 Alternative 1: Deciders16.3.2 Alternative 2: Modeling exceptions as data16.3.3 divertTo16.3.4 Restarting the source16.4 Adding elements dynamically to a streamSummary
A.1 Installing the JDKA.1.1 Installing SDKMAN!A.1.2 Installing JavaA.2 Installing sbtA.3 Installing DockerA.4 Installing curlA.5 Installing grpcurlA.6 Installing kcatA.7 Installing the AWS CLIA.8 Installing Minikube
B.1 Do microservices exist?B.1.1 Let’s bound a contextB.1.2 Characteristics of better services: What were we missing?B.1.3 Jailed services and other isolationsB.1.4 Some challenges from isolationB.2 Architectural principlesB.2.1 Event-driven systemsB.2.2 Architectural patternsB.2.3 Business abstractions

Content preview from Akka in Action, Second Edition

15 Akka betting house, part 2

This chapter covers

Creating projections and endpoints for them
Running an app locally and in Kubernetes

We began the betting-house example in chapter 12. There we had the three main actors representing the business: the bet, the market, and the wallet. The market is a specific sports event with odds to bet against. The wallet represents the account of a user with its balance. The bet is the amount of money invested in a market and backed by a wallet.

In this chapter, you add two projections: one for the markets and one for the bets. These projections transform some of the events they receive from the entities and push them—those from the markets into a Kafka topic, and those from the bets into a database (see ...