A look into the upcoming soon-to-be-stable typed Actor APIs in Akka. Shown at Scala Days NYC 2018, while Akka 2.5.13 was out. Looking at what will become the stable Akka Typed.
Building a Reactive System with Akka - Workshop @ O'Reilly SAConf NYCKonrad Malawski
Intense 3 hour workshop covering Akka Actors, Cluster, Streams, HTTP and more. Including very advanced patterns.
Presented with Henrik Engstrom at O'Reilly Software Architecture Conference in New York City in 2017
Akka-chan's Survival Guide for the Streaming WorldKonrad Malawski
In this talk we dive into the various kinds of "Streaming", what it actually means, where to use which technology and specifically take a look at Akka Streams and their specific use case and strengths.
Reactive Streams are a cross-company initiative first ignited by Lightbend in 2013, soon to be joined by RxJava and other implementations focused on solving a very similar problem: asynchronous non-blocking stream processing, with guaranteed over-flow protection. Fast forward to 2016 and now these interfaces are part of JSR-266 and proposed for JDK9.
In this talk we'll first disambiguate what the word Stream means in this context (as it's been overloaded recently by various different meanings), then look at how its protocol works and how one might use it in the real world showing examples using existing implementations.
We'll also have a peek into the future, to see what the next steps for such collaborative protocols and the JDK ecosystem are in general.
Building a Reactive System with Akka - Workshop @ O'Reilly SAConf NYCKonrad Malawski
Intense 3 hour workshop covering Akka Actors, Cluster, Streams, HTTP and more. Including very advanced patterns.
Presented with Henrik Engstrom at O'Reilly Software Architecture Conference in New York City in 2017
Akka-chan's Survival Guide for the Streaming WorldKonrad Malawski
In this talk we dive into the various kinds of "Streaming", what it actually means, where to use which technology and specifically take a look at Akka Streams and their specific use case and strengths.
Reactive Streams are a cross-company initiative first ignited by Lightbend in 2013, soon to be joined by RxJava and other implementations focused on solving a very similar problem: asynchronous non-blocking stream processing, with guaranteed over-flow protection. Fast forward to 2016 and now these interfaces are part of JSR-266 and proposed for JDK9.
In this talk we'll first disambiguate what the word Stream means in this context (as it's been overloaded recently by various different meanings), then look at how its protocol works and how one might use it in the real world showing examples using existing implementations.
We'll also have a peek into the future, to see what the next steps for such collaborative protocols and the JDK ecosystem are in general.
ScalaSwarm 2017 Keynote: Tough this be madness yet theres method in'tKonrad Malawski
A talk about the implications and context around API design. How APIs come to be and how to understand them. This talk was delivered as opening keynote, setting the tone, for the ScalaSwarm conference in Porto, Portugal in 2017.
The things we don't see – stories of Software, Scala and AkkaKonrad Malawski
Opening keynote for Scalapeno, Tel Aviv 2016.
The talk focuses and explains the things we don't often see explicitly and/or don't notice when doing our daily work, yet make up a large part of the ecosystem and maturity of the ecoststem as a whole. We also dive into some of the more confusing bits around using the same word about different things in software
End to End Akka Streams / Reactive Streams - from Business to SocketKonrad Malawski
The Reactive Streams specification, along with its TCK and various implementations such as Akka Streams, is coming closer and closer with the inclusion of the RS types in JDK 9. Using an example Twitter-like streaming service implementation, this session shows why this is a game changer in terms of how you can design reactive streaming applications by connecting pipelines of back-pressured asynchronous processing stages. The presentation looks at the example from two perspectives: a raw implementation and an implementation addressing a high-level business need.
[Japanese] How Reactive Streams and Akka Streams change the JVM Ecosystem @ R...Konrad Malawski
Japanese subtitles by Yugo Maede-san, thank you very much. Japanese subtitled version of the "How Reactive Streams and Akka Streams change the JVM Ecosystem". http://www.slideshare.net/ktoso/how-reactive-streams-akka-streams-change-the-jvm-ecosystem
Over the past few years, web-applications have started to play an increasingly important role in our lives. We expect them to be always available and the data to be always fresh. This shift into the realm of real-time data processing is now transitioning to physical devices, and Gartner predicts that the Internet of Things will grow to an installed base of 26 billion units by 2020.
Reactive web-applications are an answer to the new requirements of high-availability and resource efficiency brought by this rapid evolution. On the JVM, a set of new languages and tools has emerged that enable the development of entirely asynchronous request and data handling pipelines. At the same time, container-less application frameworks are gaining increasing popularity over traditional deployment mechanisms.
This talk is going to give you an introduction into one of the most trending reactive web-application stack on the JVM, involving the Scala programming language, the concurrency toolkit Akka and the web-application framework Play. It will show you how functional programming techniques enable asynchronous programming, and how those technologies help to build robust and resilient web-applications.
Distributed Consensus A.K.A. "What do we eat for lunch?"Konrad Malawski
Distributed Consensus is everywhere! Even if not obvious at first, most apps nowadays are distributed systems, and these sometimes have to "agree on a value", this is where consensus algorithms come in. In this session we'll look at the general problem and solve a few example cases using the RAFT algorithm implemented using Akka's Actor and Cluster modules.
Apache Camel Introduction & What's in the boxClaus Ibsen
Slides from JavaBin talk in Grimstad Norway, presented by Claus Ibsen in February 2016.
This slide deck is full up to date with latest Apache Camel 2.16.2 release and includes additional slides to present many of the features that Apache Camel provides out of the box.
Reactive Streams: Handling Data-Flow the Reactive WayRoland Kuhn
Building on the success of Reactive Extensions—first in Rx.NET and now in RxJava—we are taking Observers and Observables to the next level: by adding the capability of handling back-pressure between asynchronous execution stages we enable the distribution of stream processing across a cluster of potentially thousands of nodes. The project defines the common interfaces for interoperable stream implementations on the JVM and is the result of a collaboration between Twitter, Netflix, Pivotal, RedHat and Typesafe. In this presentation I introduce the guiding principles behind its design and show examples using the actor-based implementation in Akka.
Introduction to Akka slide was presented to HyScala - Dec 2016 meet-up. Just prepared for the impatient and not goes too deep in to various aspects of Akka.
Understanding Akka Streams, Back Pressure, and Asynchronous ArchitecturesLightbend
The term 'streams' has been getting pretty overloaded recently–it's hard to know where to best use different technologies with streams in the name. In this talk by noted hAkker Konrad Malawski, we'll disambiguate what streams are and what they aren't, taking a deeper look into Akka Streams (the implementation) and Reactive Streams (the standard).
You'll be introduced to a number of real life scenarios where applying back-pressure helps to keep your systems fast and healthy at the same time. While the focus is mainly on the Akka Streams implementation, the general principles apply to any kind of asynchronous, message-driven architectures.
ScalaSwarm 2017 Keynote: Tough this be madness yet theres method in'tKonrad Malawski
A talk about the implications and context around API design. How APIs come to be and how to understand them. This talk was delivered as opening keynote, setting the tone, for the ScalaSwarm conference in Porto, Portugal in 2017.
The things we don't see – stories of Software, Scala and AkkaKonrad Malawski
Opening keynote for Scalapeno, Tel Aviv 2016.
The talk focuses and explains the things we don't often see explicitly and/or don't notice when doing our daily work, yet make up a large part of the ecosystem and maturity of the ecoststem as a whole. We also dive into some of the more confusing bits around using the same word about different things in software
End to End Akka Streams / Reactive Streams - from Business to SocketKonrad Malawski
The Reactive Streams specification, along with its TCK and various implementations such as Akka Streams, is coming closer and closer with the inclusion of the RS types in JDK 9. Using an example Twitter-like streaming service implementation, this session shows why this is a game changer in terms of how you can design reactive streaming applications by connecting pipelines of back-pressured asynchronous processing stages. The presentation looks at the example from two perspectives: a raw implementation and an implementation addressing a high-level business need.
[Japanese] How Reactive Streams and Akka Streams change the JVM Ecosystem @ R...Konrad Malawski
Japanese subtitles by Yugo Maede-san, thank you very much. Japanese subtitled version of the "How Reactive Streams and Akka Streams change the JVM Ecosystem". http://www.slideshare.net/ktoso/how-reactive-streams-akka-streams-change-the-jvm-ecosystem
Over the past few years, web-applications have started to play an increasingly important role in our lives. We expect them to be always available and the data to be always fresh. This shift into the realm of real-time data processing is now transitioning to physical devices, and Gartner predicts that the Internet of Things will grow to an installed base of 26 billion units by 2020.
Reactive web-applications are an answer to the new requirements of high-availability and resource efficiency brought by this rapid evolution. On the JVM, a set of new languages and tools has emerged that enable the development of entirely asynchronous request and data handling pipelines. At the same time, container-less application frameworks are gaining increasing popularity over traditional deployment mechanisms.
This talk is going to give you an introduction into one of the most trending reactive web-application stack on the JVM, involving the Scala programming language, the concurrency toolkit Akka and the web-application framework Play. It will show you how functional programming techniques enable asynchronous programming, and how those technologies help to build robust and resilient web-applications.
Distributed Consensus A.K.A. "What do we eat for lunch?"Konrad Malawski
Distributed Consensus is everywhere! Even if not obvious at first, most apps nowadays are distributed systems, and these sometimes have to "agree on a value", this is where consensus algorithms come in. In this session we'll look at the general problem and solve a few example cases using the RAFT algorithm implemented using Akka's Actor and Cluster modules.
Apache Camel Introduction & What's in the boxClaus Ibsen
Slides from JavaBin talk in Grimstad Norway, presented by Claus Ibsen in February 2016.
This slide deck is full up to date with latest Apache Camel 2.16.2 release and includes additional slides to present many of the features that Apache Camel provides out of the box.
Reactive Streams: Handling Data-Flow the Reactive WayRoland Kuhn
Building on the success of Reactive Extensions—first in Rx.NET and now in RxJava—we are taking Observers and Observables to the next level: by adding the capability of handling back-pressure between asynchronous execution stages we enable the distribution of stream processing across a cluster of potentially thousands of nodes. The project defines the common interfaces for interoperable stream implementations on the JVM and is the result of a collaboration between Twitter, Netflix, Pivotal, RedHat and Typesafe. In this presentation I introduce the guiding principles behind its design and show examples using the actor-based implementation in Akka.
Introduction to Akka slide was presented to HyScala - Dec 2016 meet-up. Just prepared for the impatient and not goes too deep in to various aspects of Akka.
Understanding Akka Streams, Back Pressure, and Asynchronous ArchitecturesLightbend
The term 'streams' has been getting pretty overloaded recently–it's hard to know where to best use different technologies with streams in the name. In this talk by noted hAkker Konrad Malawski, we'll disambiguate what streams are and what they aren't, taking a deeper look into Akka Streams (the implementation) and Reactive Streams (the standard).
You'll be introduced to a number of real life scenarios where applying back-pressure helps to keep your systems fast and healthy at the same time. While the focus is mainly on the Akka Streams implementation, the general principles apply to any kind of asynchronous, message-driven architectures.
Everyone in the Scala world is using or looking into using Akka for low-latency, scalable, distributed or concurrent systems. I'd like to share my story of developing and productionizing multiple Akka apps, including low-latency ingestion and real-time processing systems, and Spark-based applications.
When does one use actors vs futures?
Can we use Akka with, or in place of, Storm?
How did we set up instrumentation and monitoring in production?
How does one use VisualVM to debug Akka apps in production?
What happens if the mailbox gets full?
What is our Akka stack like?
I will share best practices for building Akka and Scala apps, pitfalls and things we'd like to avoid, and a vision of where we would like to go for ideal Akka monitoring, instrumentation, and debugging facilities. Plus backpressure and at-least-once processing.
This is a work in progress of a talk for the Scala User Group in Tokyo.
It touches on basics and some ideas behind Reactive Streams as well as the implementation shipped by Akka.
Presentation for the kick-off meeting for the meetup:
"Reactive Programming Enthusiasts Denver". This talks about concurrency, non-blocking, scala, futures, akka, play framework, and other concepts of reactive programming.
During the talk, we will build a simple web app using Lift and then introduce Akka ( http://akkasource.org) to help scale it. Specifically, we will demonstrate Remote Actors, "Let it crash" fail over, and Dispatcher. Other Scala oriented tools we will use include sbt and ENSIME mode for emacs.
Akka A to Z: A Guide To The Industry’s Best Toolkit for Fast Data and Microse...Lightbend
Microservices. Streaming data. Event Sourcing and CQRS. Concurrency, routing, self-healing, persistence, clustering… You get the picture. The Akka toolkit makes all of this simple for Java and Scala developers at Amazon, LinkedIn, Starbucks, Verizon and others. So how does Akka provide all these features out of the box?
Join Hugh McKee, Akka expert and Developer Advocate at Lightbend, on an illustrated journey that goes deep into how Akka works–from individual Akka actors to fully distributed clusters across multiple datacenters.
Similar to Networks and Types - the Future of Akka @ ScalaDays NYC 2018 (20)
In this talk we explain the basics of Typed Actors as they are to land in Akka as a stable module in 2018. Typed Actors ("Akka Typed") re-introduce typesafety to concurrency and distributed systems thanks to the abstraction of a typed actor reference.
Akka Streams (0.7) talk for the Tokyo Scala User Group, hosted by Dwango.
Akka streams are an reactive streams implementation which allows for asynchronous back-pressured processing of data in complext pipelines. This talk aims to highlight the details about how reactive streams work as well as some of the ideas behind akka streams.
Short lightning talk about the HBase plugin for Akka Persistence and how it's how key design was specifically tuned for increasing numeric sequential idenfitiers, so that the cluster can be utilised properly.
https://github.com/ktoso/akka-persistence-hbase
Event sourcing and Domain Driven Design are techniques that allow you to model your business more truthfully - by expressing it via commands, events and aggregates etc. The new akka-persistence module, included in Akka since the 2.3 release is aimed at easing implementing event sourced applications. Turns out the actor model and events as messages fit in here perfectly. During this session we'll discover how to build reactive, event sourcing based apps using the new abstractions provided, and investigate how to implement your own journals to back these persistent event sourced actors.
Akka persistence == event sourcing in 30 minutesKonrad Malawski
Akka 2.3 introduces akka-persistence, a wonderful way of implementing event-sourced applications. Let's give it a shot and see how DDD and Akka are a match made in heaven :-)
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
How world-class product teams are winning in the AI era by CEO and Founder, P...
Networks and Types - the Future of Akka @ ScalaDays NYC 2018
1. Networks & Types
Konrad `ktoso` Malawski, Akka Team
Scala Days New York, June 2018
Art by mastermind31, also “a sneaky reference”, extra points if you “get it”.
The Future[T] of Akka (Actors)
2. Konrad `ktoso` Malawski
Akka Team
Java Champion
Reactive Streams TCK
Scala Library Improvement Process Committee Member
GeeCON Teamakka.io
typesafe.com
geecon.org
Java.pl / KrakowScala.pl
sckrk.com / meetup.com/Paper-Cup @ London
GDGKrakow.pl
lambdakrk.pl @ Tokyo, Japan
3. Bear with me today,
long intro this time,
but likely most content-heavy talk in quite a while.
5. - Distributed programming made simple
- High performance messaging (up to 1 million msgs/s on Artery)
- Asynchronous and Reactive by default
- Initiator of Reactive Streams initiative, now part of JDK9
- Productive development, with tuned type-safe tools
What does Akka solve?
21. Last years of Akka have all been about types
Akka hates Types, dude. Trust me.
Mmmm, cereal…
22. Last years of Akka have all been about types
Focus and large projects since 2013/2014:
Spray => Akka HTTP, 2013 (!)
incredibly typed HTTP APIs / DSL
23. Last years of Akka have all been about types
Focus and large projects since 2013/2014:
Spray => Akka HTTP, 2013 (!)
incredibly typed HTTP APIs / DSL
Reactive Streams, 2014(Mathias and Johannes did first-first-first impl!)
Akka Streams – completely Typed, part of JDK9+
Alpakka, 2016
Modern take on “Camel”-like integrations, but streaming
24. Last years of Akka have all been about types
Focus and large projects since 2013/2014:
Spray => Akka HTTP, 2013 (!)
incredibly typed HTTP APIs / DSL
Reactive Streams, 2014(Mathias and Johannes did first-first-first impl!)
Akka Streams – completely Typed, part of JDK9+
Alpakka, 2016
Modern take on “Camel”-like integrations, but streaming
Akka Typed (and Cluster, Persistence, …), 2014-ish~
Experiments since 2014, active “finalizing” since 2016
Right now: full team effort and going to ship prod-ready this year.
25. Spray => Akka HTTP, 2013 (!)
incredibly typed HTTP APIs / DSL
Reactive Streams, 2014(Mathias and Johannes did first-first-first impl!)
Akka Streams – completely Typed, part of JDK9+
Alpakka, 2016
Modern take on “Camel”-like integrations, but streaming
Akka Typed (and Cluster, Persistence, …), 2014-ish~
Experiments since 2014, active “finalizing” since 2016
Right now: full team effort and going to ship prod-ready this year.
Last years of Akka have all been about types
Focus and large projects since 2014:
Typed
Typed
Typed
Typed
Distributed
Distributed extensions via StreamRefs,
(yes, we’re aware of RSocket :-))
Fully Streaming HTTP server,
incl. WIP HTTP/2
26. - More compile time type-safety, results in less runtime debugging.
- Runtime debugging is much harder than compile time
- Resulting in a more productive programming team.
Types help build more reliable systems in production.
Not something Akka was arguing against,
however with long Erlang inspiration,
we did not help much with Type-safety in Actors…
The need for strong/strict typing
27. - Inherently at odds with concurrent and especially distributed computing
- Not trivial problem, unless simplified:
Annual topic of multiple research papers to bring type-safety to the Actor model
- “TAkka” 2014, Phillip Wadler et al, University of Edinburgh
- “Reactors, Channels and Event Streams …” 2015,
Aleksandar Prokopec, Martin Odersky, EPFL
- Typed Actors [RIP],
Not direct implementation of these papers, however certainly inspired by them.
The need for strong/strict typing
29. Issues with untyped Actors
1. can send “wrong message” to an actor
• because ActorRef.tell(AnyRef)
• hard to navigate / understand code with ActorRefs being passed around
2. interop with Futures / mutable “sender()” / accidental closing over m. state
3. “actors don’t compose!” (the same way as functional concepts do)
“classic”Valid complaints about / issues with actors:
30. Issues with untyped Actors
1. can send “wrong message” to an actor
• because ActorRef.tell(AnyRef)
• hard to navigate / understand code with ActorRefs being passed around
2. interop with Futures / mutable “sender()” / accidental closing over m. state
3. “actors don’t compose!” (the same way as functional concepts do)
“classic”Valid complaints about / issues with actors:
1. flow-control not built-into Actor messaging
2. supervision too often misunderstood / abused / backoff limitations
3. actorSelection feature often abused (String => ActorRef)
Akka Team’s extras:
31. Issues with untyped Actors
1. “entirely pure”, however we love pure domain models *within* Actors (!)
2. “super mega high performance”, but “high-performance-ish enough”
You *can* build a kernel-bypass high performance super tunes blog…
but why would you (except that it’s “hardcore” (and fun :-)))
4. “build only for the local case”.
The moment you go concurrent / multi-core / multi-socket…
you have all the complexities of distributed systems already,
not hiding it yields understandable systems.
And, “no.”
It was never and will never be the main goal of Actors to:
32. Untyped Actors
• “sender()” propagated automatically
• any message type can be sent to any Actor
• actor’s def receive = { … } don’t return values
Untyped actors => Akka Typed
33. Untyped Actors
• “sender()” propagated automatically
• any message type can be sent to any Actor
• actor’s def receive = { … } don’t return values
Akka Actor Typed
• “sender” is part of the protocol
• only the right type of messages can be sent:
ActorRef[MessageProtocol]
• behaviors always return new behaviors
(state machines for the win)
Untyped Actors => Akka Typed
34. class MyActor extends Actor {
def receive: Any => Unit = {
case Msg(a) =>
sender() ! “Hi there!”
// …
}
}
Reminder of Akka “Classic” Actors
“classic”
40. ActorRef[T] — the “big deal”
In this talk, I will argue that:
While ActorRef[T] is a great change,
the potential and compositional power of Behavior[T]
by far outshines it, by unlocking new ways to compose behaviors/actors.
43. Akka Actor Typed basics (getting our first ActorRef)
Akka Typed top level behavior and spawning #25223
import akka.NotUsed
import akka.actor.typed._
import akka.actor.typed.scaladsl._
val sys =
ActorSystem(Behaviors.setup { context
context.spawn(schedulingMaster, "schedulingMaster")
context.spawn(otherSubsystem, "subsystemMaster")
Behavior.ignore
}, name = “ScalaDaysSystem")
May SLIGHTLY Change, some simplifications here…
44. Akka Actor Typed basics (getting our first ActorRef)
Akka Typed top level behavior and spawning #25223
import akka.NotUsed
import akka.actor.typed._
import akka.actor.typed.scaladsl._
val sys: ActorSystem[NotUsed] =
ActorSystem(Behaviors.setup { context
context.spawn(SchedulingMaster, "schedulingMaster")
context.spawn(OtherSubsystem, "subsystemMaster")
Behavior.ignore
}, name = "ScalaDaysSystem")
// ActorSystem[T] extends ActorRef[T]
sys ! NotUsed
May SLIGHTLY Change, some simplifications here…
45. Akka Actor Typed basics (getting our first ActorRef)
val sys: ActorRef[NotUsed] = ???
sys ! NotUsed
sys ! “LOL!”
There’s much more to it than it looks like though…
[error] /Users/ktoso/code/akka/akka-actor-typed/src/main/scala/akka/Example.scala:17:11: type mismatch;
[error] found : String(“LOL!”)
[error] required: akka.NotUsed
[error] ref ! "LOL"
[error] ^
[error] one error found
TENS OF YEARS OF RESEARCH AND DEVELOPMENT!!!
A M A Z I N G.
46. Akka Actor Typed basics (getting our first ActorRef)
object SchedulingMaster {
sealed trait Protocol
final case class Register(name: String) extends Protocol
def apply: Behavior[Protocol] =
behavior(Set.empty)
private def behavior(registered: Set[String]): Behavior[Protocol] =
Behaviors.receiveMessage[Protocol] {
case Register(name)
behavior(registered + name)
}
}
val ref: ActorRef[SchedulingMaster.Protocol] =
context.spawn(SchedulingMaster, "schedulingMaster")
49. ActorSystem[T] — currently using an “emulation layer”
Co-existence
- tell between typed/untyped, spawn on untyped etc.
- https://akka.io/blog/2017/05/06/typed-coexistence
50. ActorSystem[T] — currently using an “emulation layer”
Co-existence
& Low-risk migration
- Currently running on thin “emulation layer”
- More and more things implemented “natively” (e.g. Persistence)
- tell between typed/untyped, spawn on untyped etc.
- https://akka.io/blog/2017/05/06/typed-coexistence
54. Decorating behaviors to get more capabilities
def behavior =
Behaviors.receiveMessage { m
println("Received: " + m)
Behaviors.same
}
“Oh, but I need logging…”
“Oh, but I need to spawn actors…”
55. Decorating behaviors to get more capabilities
def behavior =
Behaviors.receiveMessage { m
println("Received: " + m)
Behaviors.same
}
def behavior =
Behaviors.setup[Message] { context
Behaviors.receiveMessage { m
context.log.info("Received: " + m)
Behaviors.same
}
}
56. Decorating behaviors to get more capabilities
def behavior =
Behaviors.receiveMessage { m
println("Received: " + m)
Behaviors.same
}
import scala.concurrent.duration._
trait Message
object Timeout extends Message
def behavior: Behavior[Message] =
Behaviors.withTimers[Message] { timers
timers.startSingleTimer("timerKey", Timeout, 10.seconds)
Behaviors.receiveMessage {
case Timeout
Behaviors.stopped
case m
Behaviors.ignore
}
}
“Oh, but I need timers…”
58. Behavior.orElse
def ping(counters: Map[String, Int]): Behavior[Ping] = {
val ping1: Behavior[Ping] = Behaviors.receiveMessagePartial {
case Ping1(replyTo: ActorRef[Pong])
val newCounters = counters.updated("ping1", counters.getOrElse("ping1", 0) + 1)
replyTo ! Pong(newCounters("ping1"))
ping(newCounters)
}
val ping2: Behavior[Ping] = Behaviors.receiveMessage {
case Ping2(replyTo: ActorRef[Pong])
val newCounters = counters.updated("ping2", counters.getOrElse("ping2", 0) + 1)
replyTo ! Pong(newCounters("ping2"))
ping(newCounters)
case _ Behaviors.unhandled
}
ping1.orElse(ping2)
}
}
sealed trait Ping
case class Ping1(replyTo: ActorRef[Pong]) extends Ping
case class Ping2(replyTo: ActorRef[Pong]) extends Ping
case class Pong(counter: Int)
59. ActorRef[T]
def ping(counters: Map[String, Int]): Behavior[Ping] = {
val ping1: Behavior[Ping] = Behaviors.receiveMessagePartial {
case Ping1(replyTo: ActorRef[Pong])
val newCounters = counters.updated("ping1", counters.getOrElse("ping1", 0) + 1)
replyTo ! Pong(newCounters("ping1"))
ping(newCounters)
}
val ping2: Behavior[Ping] = Behaviors.receiveMessage {
case Ping2(replyTo: ActorRef[Pong])
val newCounters = counters.updated("ping2", counters.getOrElse("ping2", 0) + 1)
replyTo ! Pong(newCounters("ping2"))
ping(newCounters)
case _ Behaviors.unhandled
}
ping1.orElse(ping2)
}
}
sealed trait Ping
case class Ping1(replyTo: ActorRef[Pong]) extends Ping
case class Ping2(replyTo: ActorRef[Pong]) extends Ping
case class Pong(counter: Int)
60. This WOULD be possible on Scala 3…!
val b: Behavior[A | B] = canA.orElse(canB)
THIS DOES NOT WORK ON SCALA 2.x
This is a “wild speculations” slide.
Do not quote me on these…
61. This WOULD be possible on Scala 3…!
val b: Behavior[A | B] = canA.orElse(canB)
Scala 2.x: Nein! Was ist denn ein “A | B”?
Das verstehe ich doch überhaupt nicht!
THIS DOES NOT WORK ON SCALA 2.x
This is a “wild speculations” slide.
Do not quote me on these…
62. This WOULD be possible on Scala 3…!
val b: Behavior[A | B] = canA.orElse(canB)
We don’t have Union Types…
THIS DOES NOT WORK ON SCALA 2.x
This is a “wild speculations” slide.
Do not quote me on these…
Scala 2.x: Nein! Was ist denn ein “A | B”?
Das verstehe ich doch überhaupt nicht!
63. This WOULD be possible on Scala 3…!
val b: Behavior[A | B] = canA.orElse(canB)
But wait…! Scala 3 will have union types!
https://dotty.epfl.ch/docs/reference/union-types.html
THIS DOES NOT WORK ON SCALA 2.x
This is a “wild speculations” slide.
Do not quote me on these…
64. What can we do until then though? narrow/widen
/**
* Narrow the type of this Behavior, which is always a safe operation.
*/
final def narrow[U <: T]: Behavior[U] = this.asInstanceOf[Behavior[U]]
65. What can we do until then though? narrow/widen
/**
* Narrow the type of this Behavior, which is always a safe operation.
*/
final def narrow[U <: T]: Behavior[U] = this.asInstanceOf[Behavior[U]]
import akka.actor.typed.scaladsl.Behaviors
trait Animal
trait Cat extends Animal
trait Dog extends Animal
trait Capybara extends Animal
val doc: Behaviors.Receive[Animal] = Behaviors.receiveMessage[Animal] { msg
Behaviors.same
}
val capyDoc: Behavior[Capybara] = doc.narrow[Capybara]
66. case class InternalProtocol(name: String, replyTo: ActorRef[InternalReply])
case class InternalReply(id: Int)
val doc: Behavior[Animal] =
Behaviors.receive[AnyRef] { // The “cop out” method
case (context, msg: Animal)
val registration: ActorRef[InternalProtocol] =
context.spawnAnonymous(
Behaviors.receiveMessage[InternalProtocol] {
case InternalProtocol(name, replyTo)
replyTo ! InternalReply(1337)
Behaviors.stopped
})
registration ! InternalProtocol(msg.getClass.getName, context.self)
Behaviors.same
case (context, confirmed: InternalReply) // handle “internal”
println("Confirmed: " + confirmed.id)
Behaviors.same
}.narrow[Animal] // exposing still “safely”
What can we do until then though? narrow/widen
Use narrow to narrow down what
types you allow others to send to you.
67. // this doc can only handle Capybaras:
val capyDoctor: Behaviors.Receive[Capybara] =
Behaviors.receiveMessage[Capybara] {
kapi Behaviors.same
}
val adapting: Behavior[Animal] =
capyDoctor.widen[Animal] {
case dog: Dog
// it's kind of like a capybara...
new Capybara { val actually = dog }
} // all others => Unhandled
We can also “widen”
/**
* Widen the wrapped Behavior by placing a funnel in front of it: the supplied
* PartialFunction decides which message to pull in (those that it is defined
* at) and may transform the incoming message to place them into the wrapped
* Behavior’s type hierarchy. Signals are not transformed.
*
* Example:
* {{{
* receive[String] { (ctx, msg) => println(msg); same }.widen[Number] {
* case b: BigDecimal => s"BigDecimal($b)"
* case i: BigInteger => s"BigInteger($i)"
* // drop all other kinds of Number
* }
* }}}
*/
def widen[U](matcher: PartialFunction[U, T]): Behavior[U] =
BehaviorImpl.widened(behavior, matcher)
Use widen to “widen” the set of types you can handle,
by adapting them or leaving them unhandled.
68. Behaviors.receive[Internal] {
case (context, _)
val adapterRef: ActorRef[ExternalProtocol] =
context.messageAdapter[ExternalProtocol] {
case other if other.isSomething new InternalSomething(other)
case other new InternalWrappedOther(other)
}
// …
}
Message adapters; “reply to me, and I’ll adapt to my T”
Use messageAdapter to create
“mini ActorRef” that translates
someone’s protocol => your own protocol.
69. def ask[U](message: ActorRef[U] A)
(implicit timeout: Timeout, scheduler: Scheduler): Future[U] = ???
def ask[Req, Res](otherActor: ActorRef[Req])
(createRequest: ActorRef[Res] Req)
(mapResponse: Try[Res] T)
(implicit responseTimeout: Timeout, classTag: ClassTag[Res]): Unit = ???
Various `ask` patterns
Ask received a number of versions, that cut more and more clutter
depending on how much context it has available.
70. Behavior[A | B]
What can we do until then though?
NOT AT ALL PROVEN CRAZY IDEA
DON’T TRUST ME ON THIS (YET)
// can't do this nowadays:
// val all: Behavior[???] = canA orElse canB // nope
val all: Behavior[Union2[A, B]] = anyOf(canA, canB) // special behavior impl
val allRef: ActorRef[Union2[A, B]] = context.spawn(all, "fake-union")
val a: A = ???
val b: B = ???
allRef ! a // implicitly packed as Union2[A, B]
allRef ! b // implicitly packed as Union2[A, B]
Crazy experiments,
could we emulate…
https://github.com/akka/akka/issues/25251
76. “classic” Note the difference between
messages which are unhandled.
The actor exists, but did not handle the msg.
77. “classic” actorSelection with “wrong” name
also results in dead letters.
We don’t even know if this actor ever lived!
78. “classic”
Note also that String => ActorRef[T] could never yield the “right T”.
We need something:
Less error prone and more type-safe.
And even more useful…
String => ActorRef[T] can’t ever possibly give the right T
88. Moving from Classic to Typed, *EASILY*
class ChatRoomBehavior extends Actor {
private var sessions: List[ActorRef[SessionCommand]] =
List.empty
override def receive = {
case GetSession(screenName, client)
. . .
case PublishSessionMessage(screenName, message)
. . .
}
}
}
89. Moving from Classic to Typed, *EASILY*
class ChatRoomBehavior(ctx: ActorContext[RoomCommand])
extends MutableBehavior[RoomCommand] {
private var sessions: List[ActorRef[SessionCommand]] = List.empty
override def onMessage(msg: RoomCommand): Behavior[RoomCommand] = {
msg match {
case GetSession(screenName, client)
. . .
Behaviors.same
case PublishSessionMessage(screenName, message)
. . .
this
}
}
}
class ChatRoomBehavior extends Actor {
private var sessions: List[ActorRef[SessionCommand]] =
List.empty
override def receive {
case GetSession(screenName, client)
. . .
case PublishSessionMessage(screenName, message)
. . .
}
}
}
90. “classic”
Yes, you can mix-and-match all “styles” of Behaviors.
Yes, you can also mix JavaDSL/ScalaDSL — they share the Behavior type.
String => ActorRef[T] can’t ever possibly give the right T
92. Meant to:
- handle “failures”, not “errors”.
- be always-on, hierarchical
Is often abused to:
- replace try/catch,Try,Either,Validation etc.
Not able to express “backoff”:
- is implemented as separate BackoffSupervisor
“Classic supervision”: always on, in parent actor
“classic”Supervision in
93. Declarative, composable supervision
val ref = Behaviors.supervise(targetBehavior)
.onFailure[SomeException](SupervisorStrategy.restart)
Mini DSL for building supervision, which is also “just” a Behavior[T]
94. Declarative, composable supervision
val ref = Behaviors.supervise(targetBehavior)
.onFailure[SomeException](SupervisorStrategy.restart)
supervise(
supervise(
targetBehavior
).onFailure[Exc2](SupervisorStrategy.resume)
).onFailure[Exc3](SupervisorStrategy.restart)
Mini DSL for building supervision, which is also “just” a Behavior[T]
Supports nesting , for sharing logic for “common handler” etc
98. Downsides of typedness…
Not so suprisingly, more types may mean more “dancing around”,
getting the types “right”.
You will thank yourself in the future though,
once you have to go back and maintain a piece of code :-)
Don’t fear dropping to MutableBehavior[T] if it feels right!
99. Flow Control
Wouldn’t it be nice if we spent years of work on a flow-control protocol…
… and could actually apply it to many areas of Akka…?
Extra:
103. Akka Streams
…which implement Reactive Streams
Typed by default
…which is the async-flow-control standard
…which is now also part of JDK9+ (j.u.c.Flow)
104. Fast Publisher will send at-most 3 elements.
This is pull-based-backpressure.
Reactive Streams: “dynamic push/pull”
106. StreamRefs — new feature in Akka 2.5.10
“Reactive Streams semantics,
over network boundaries.”
107. StreamRefs — new feature in Akka 2.5.10
“Reactive Streams semantics,
over network boundaries.”
“Like ActorRef[T], but for Akka Streams”
Very lightweight, and simple.
108. StreamRefs — new feature in Akka 2.5.10
By design NOT a“distributed automatic stream
processing deployment and management framework”.
(e.g. how Spark, Flink or Beam could be described).
Ideal for
combining Alpakka Enterprise Integration,
Data Processing or Ingestion Pipelines,
or back-pressured / flow-controlled messaging between systems.
109. See also, Nitesh Kant, Netflix @ Reactive Summit
https://www.youtube.com/watch?v=5FE6xnH5Lak
Life without StreamRefs
110. HTTP/1.1 503 Service Unavailable
HTTP/1.1 503 Service Unavailable
And then:
Throttling as represented by 503 responses…
Applying circuit breakers…
Introducing manual flow control…
Life without StreamRefs
114. “origin” side “remote” side
.runWith(StreamRefs.sourceRef)
run Source and,
materialize SourceRef
SourceRef
Source
Arbitrarily complex
Source graph
.source.runWith(any Sink)
Establishes link and demands for elements to be sent to remote side
SourceRef
send to remote recipient
(e.g. via actor messaging)
SourceRef — high-level overview
117. Can we apply this to
Actor messaging?
Somewhat.
118. Better flow control mechanisms in Typed Actors
Could we combine StreamRef semantics + re-delivery…
with pre-packaged Behaviors / “companions”…?
Experiment here: https://github.com/akka/akka/pull/25099
120. In other news…
Artery (UDP, Aeron) transport – soon to become stable
Artery TCP+TLS transport – new, soon to become stable
Akka Cluster Multi-DC – dc awareness fully supported
Akka Multi-DC Persistence* – fully supported multi-dc persistence
Typed Persistence – Akka Persistence, but fully typed, soon ready
Alpakka (Akka Streams connectors to various tech)
125. Artery: ActorRef / Manifest Compression
In this case ActorRef compression reduced the size of a small envelope size by 74%
- from 162 to 42 bytes (sic!).
132. More Cloud Native-ness / aware-ness
Out now:
- Multi-Datacenter awareness (OSS)
- Multi-Datacenter Replication for Akka Persistence (Commercial)
Active new development:
- “right and proper” integrations with k8s (Lightbend Orchestration,Akka Management)
135. “Zen of Akka”, ScalaDays NYC 2016
Underlying principles, best-practices, some anti-patterns
https://www.youtube.com/watch?v=vgFoKOxrTzg
Recommended viewing (selfish plug)
“The best is yet to come”, Scala Days CPH 2017
How we got here, how one thing inter-ops with another, and roadmap
https://www.youtube.com/watch?v=CGyIPVGB2-4 (~200 slides, 50 mins)
All slides on https://www.slideshare.net/ktoso
(Please give it a day for this slide deck to appear there)
136. ”Why Reactive?”, free ebook, not “sponsored” content :-)
Show it off to people new to reactive systems, to get “the idea” behind it.
bit.ly/why-reactive
Recommended reading (selfish plug)
137. New free Coursera / edx course about
Akka Typed & Akka Streams soon!
Pre annoucement :-)
138. Happy typed hakking!
Konrad `ktoso` Malawski, ktoso@lightbend.com
http://kto.so / http://konrad.malaw.ski / @ktosopl
Akka docs: akka.io/docs
Lake Ashi, Hakone, Japan