Avoid common mistakes when building distributed, asynchronous, high-performance software with the Akka toolkit and runtime. With this concise guide, author Jamie Allen provides a collection of best practices based on several years of using the actor model. The book also includes examples of actor apEffective akkaJamie allen○ REILLY。Beijing: Cambridge· Farnham·Koln· Sebastopol· TokyoEffective akkaby Jamie AllenCopyright O 2013 Jamie Allen. All rights reservedPrinted in the United States of americaPublished by o reilly media, InC, 1005 Gravenstein Highway North, Sebastopol, CA95472O Reilly books may be purchased for educational, business, or sales promotional use Online editions arealsoavailableformosttitles(http://my.safaribooksonline.com).fOrmoreinformation,contactourcorporateinstitutionalsalesdepartment800-998-9938orcorporate@oreilly.comEditor: Meghan blanchetteCover Designer: Randy ComerProduction editor: Kara ebrahimInterior Designer: David FutatoProofreader: Amanda KerseyIllustrator: Rebecca demarestFirst editionRevision history for the first Edition:2013-08-15: First releaseSeehttp://oreilly.com/catalog/errata.csp?isbn=9781449360078forreleasedetailsNutshell Handbook, the Nutshell Handbook logo, and the O Reilly logo are registered trademarks ofO ReillyMedia, Inc. Effective Akka, the image of a black grouse, and related trade dress are trademarks of o reillyMedia IncMany of the designations used by manufacturers and sellers to distinguish their products are claimed astrademarks. Where those designations appear in this book, and O Reilly Media, Inc, was aware of a trademark claim, the designations have been printed in caps or initial capsWhile every precaution has been taken in the preparation of this book, the publisher and author assume noresponsibility for errors or omissions, or for damages resulting from the use of the information containedhereinISBN:978-1-449-36007-8Table of contentsPreface1. Actor Application TypesDomain-drivenDomain-driven Messages Are FactsWork distribRouters and routesBalancing Dispatcher Will Be Deprecated SoonWork Distribution Messages Are Commands2. Patterns of Actor UsageThe Extra patternThe ProblemAvoiding askCapturing context12Sending Yourself a Timeout MessageThe Cameo pattern20The Companion Object Factory Method23How to Test This Logic233. Best practices25Actors Should Do Only One Thing25Single Responsibility Principle25Create Specific Supervisors26Keep the Error Kernel Simple28Failure zones29Avoid Blocking31Futures Delegation Example32Pre-defining Parallel Futures34Parallel Futures with the zip( Method35Sequential Futures35Callbacks versus Monadic Handling36Futures and execution Context36Push, Dont pullWhen You must block39Managed blocking in Scala39Avoid Premature Optimization40Start SimpleLayer in Complexity via indeterminism42Optimize with mutability42Prepare for Race ConditionsBe explicitName Actors and Actor System InstancesCreate Specialized Messages46Create Specialized ExceptionsBeware the Thundering Herd48Dont Expose actors49Avoid Using thisThe Companion Object Factory Method50Never Use Direct references52Dont close over variables52Use Immutable Messages with Immutable Data53Help Yourself in Production54Make debugging Easier55Add metrics55Externalize Business logicUse Semantically Useful LoggingAggregate Your Logs with a Tool Like Flume57Use Unique IDs for MessagesTune Akka Applications with the Typesafe Console58Fixing Starvation58Sizing DispatchersThe Parallelism-Factor SettingActor mailbox size60Throughput SettingEdge cases61Table of contentsPrefaceWelcome to Effective Akka. In this book, I will provide you with comprehensive infor-mation about what I've learned using the akka toolkit to solve problems for clients inmultiple industries and use cases. This is a chronicle of patterns Ive encountered, aswell as best practices for developing applications with the Akka toolkitWho this book ls forThis book is for developers who have progressed beyond the introductory stage ofwriting Akka applications and are looking to understand best practices for developmentthat will help them avoid common missteps many of the tips are relevant outside ofAkka as well, whether itis using another actor library, Erlang, or just plain asynchronousdevelopment. This book is not for developers who are new to Akka and are looking forntroductory informationWhat Problems Are We solving with Akka?The first question that has to be addressed is, what problems is Akka trying to solve forapplication developers? Primarily, Akka provides a programming model for buildingdistributed, asynchronous, high-performance software. Let's investigate each of theseindividuallDistributedBuilding applications that can scale outward, and by that I mean across multiple jvand physical machines, is very difficult. The most critical aspects a developer must keepin mind are resilience and replication: create multiple instances of similar classes forhandling failure, but in a way that also performs within the boundaries of your applications nonfunctional requirements. Note that while these aspects are important inenabling developers to deal with failures in distributed systems, there are other impor-tant aspects, such as partitioning functionality, that are not specific to failure. There isa latency overhead associated with applications that are distributed across machinesand/or JVMs due to network traffic as communication takes place between systemsThis is particularly true if they are stateful and require synchronization across nodesas messages must be serialized /marshalled, sent, received, and deserialized/unmarshalled for every messageIn building our distributed systems, we want to have multiple servers capable of handling requests from clients in case any one of them is unavailable for any reason Butwe also do not want to have to write code throughout our application focused only onthe details of sending and receiving remote messages We want our code to be declarativenot full of details about how an operation is to be done, but explaining what is to bedone. Akka gives us that ability by making the location of actors transparent acrossnodesAsynchronousAsynchrony can have benefits both within a single machine and across a distributedarchitecture. In a single node, it is entirely possible to have tremendous throughput byorganizing logic to be synchronous and pipelined. The Disruptor Pattern by LMAX isan excellent example of an architecture that can handle a great deal of events in a single-threaded model. That said, it meets a very specific use case profile: high volume, lowlatency, and the ability to structure consumption of a queue. If data is not coming intothe producer, the disruptor must find ways to keep the thread of execution busy so asnot to lose the warmed caches that make it so efficient It also uses pre-allocated mutablestates to avoid garbage collection-very efficient, but dangerous if developers dontknow what theyre doingWith asynchronous programming, we are attempting to solve the problem of not pin-ning threads of execution to a particular core, but instead allowing all threads access ina varying model of fairness. We want to provide a way for the hardware to be able toutilize cores to the fullest by staging work for execution This can lead to a lot of contextswitches, as different threads are scheduled to do their work on cores which arentfriendly to performance since data must be loaded into the on-core caches of the CPuwhen that thread uses it. So you also need to be able to provide ways to batch asynchronous execution. This makes the implementation less fair but allows the developerto tune threads to be more cache-friendlyHigh PerformanceThis is one of those loose terms that without context might not mean much. For thesake of this book, I want to define high performance as the ability to handle tremendousloads very fast while at the same time being fault tolerant. Building a distributed systemthat is extremely fast but incapable of managing failure is virtually useless: failures happen, particularly in a distributed context(network partitions, node failures, etc. ) andPrefresilient systems are able deal with the. but no one wants to create a resilient systemwithout being able to support reasonably fast executionReactive ApplicationsYou may have heard discussion, particularly around Typesafe, of creating reactive applications. My initial response to this word was to be cynical, having heard plenty ofmarketecture terms(words with no real architectural meaning for application development but used by marketing groups). However, the concepts espoused in the reactiveManifesto make a strong case for what features comprise a reactive application and whatneeds to be done to meet this model. Reactive applications are characteristically interactive, fault tolerant, scalable, and event driven. If any of these four elements are removed, it's easy to see the impact on the other threeAkka is one of the toolkits through which you can build reactive applications. Actorsare event driven by nature, as communication can only take place through messagesAkka also provides a mechanism for fault tolerance through actor supervision, and isscalable by leveraging not only all of the cores of the machine on which it's deployed,but also by allowing applplications to scale outward by using clustering and remoting todeploy the application across multiple machines or VMsUse Case for This Book: Banking Service for Account DataIn this book, we will use an example of a large financial institution that has decided thatusing existing caching strategies no longer meet the real-time needs of its business. Wewill break down the data as customers of the bank, who can have multiple accountsThese accounts need to be organized by type, such as checking, savings, brokerage, etcand a customer can have multiple accounts of each type.Conventions Used in this bookThe following typographical conventions are used in this boolitalieIndicates new terms, URLS. email addresses, filenames, and file extensionsConstant widthUsed for program listings, as well as within paragraphs to refer to program elementssuch as variable or function names, databases, data types, environment variables,statements, and keywordsConstant width boldShows commands or other text that should be typed literally by the userPrefaceConstant width italicShows text that should be replaced with user-supplied values or by values deter-mined by contextThis icon signifies a tip, suggestion, or general noteThis icon indicates a warning or cautionUsing〔 ode examplesSupplemental material (code examples, exercises, etc. is available for download athttp://examples.oreilly.com/9781449360078-files/This book is here to help you get your job done. In general, if this book includes codeexamples, you may use the code in this book in your programs and documentation. Youdo not need to contact us for permission unless you're reproducing a significant portionof the code. For example, writing a program that uses several chunks of code from thisbook does not require permission. Selling or distributing a CD-ROM of examples fromOReilly books does require permission. Answering a question by citing this book andquoting example code does not require permission. Incorporating a significant amountof example code from this book into your products documentation does requirepermissionWe appreciate, but do not require, attribution. An attribution usually includes the title,author, publisher, and ISBN. For example: Effective Akka by Jamie Allen(OReillyCopyright 2013 Jamie Allen, 978-1-449-36007-8If you feel your use of code examples falls outside fair use or the permission given above,feelfreetocontactusatpermissions@oreilly.comSafari books onlineSafario> Safari Books Online is an on-demand digital library that deliversexpert content in both book and video form from the world s leading authors in technology and businessTechnology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, prob-lem solving, learning, and certification trainingPreface