Be Reactive! at Functional and Reactive Programmers Group, Kaiserslautern March 31 2015
Report
Share
•2 likes•927 views
![Be Reactive! SUG KL March 2015
High concurrency matters
18
But there’s one thing we can all agree on: At high levels of
concurrency (thousands of connections) your server needs to go to
asynchronous non-blocking. [..] any part of your server code blocks
you’re going to need a thread. And at these levels of concurrency, you
can’t go creating threads for every connection.
From https://strongloop.com/strongblog/node-js-is-faster-than-java/](https://image.slidesharecdn.com/20150331sugkaiserslautern-150410103405-conversion-gate01/85/be-reactive-at-functional-and-reactive-programmers-group-kaiserslautern-march-31-2015-18-320.jpg?cb=1428668910)
![Be Reactive! SUG KL March 2015
Life beyond Distributed Transactions
23
In general, application developers
simply do not implement large
scalable applications assuming
distributed transactions. When they
attempt to use distributed
transactions, the projects founder
because the performance costs and
fragility make them impractical. [..]
Instead, applications are built using
different techniques which do not
provide the same transactional
guarantees but still meet the needs of
their businesses.](https://image.slidesharecdn.com/20150331sugkaiserslautern-150410103405-conversion-gate01/85/be-reactive-at-functional-and-reactive-programmers-group-kaiserslautern-march-31-2015-23-320.jpg?cb=1428668910)
Be Reactive! at Functional and Reactive Programmers Group, Kaiserslautern March 31 2015
•2 likes•927 views
Report
Share
Download to read offline
If you deal with distributed, fault-tolerant systems, you've sooner or later come across the "Reactive Manifesto" meet (if you haven't so far, you have now: "http://www.reactivemanifesto.org/"). But, as befits a manifesto, it sets out a programmatic vision, without providing detailed explanations and guidelines for implementation. In this talk I discuss the reactive traits, and try to bring it down a level to technical properties: What is Reactive code, how do I put the principles into practice, and what are anti-patterns, which are to be avoided in reactive systems? And what does this all have to do with functional programming? The event: http://www.meetup.com/Reactive-and-Functional-Programming-Meetup-Pfalz/events/220455257/ Sources: * JVM Implementation Challenges ("Threads are passé"): https://www.jfokus.se/jfokus15/preso/JVMChallenges.pdf * The Problem With Threads: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf * Life Beyond Distributed Transactions PDF: https://github.com/papers-we-love/papers-we-love/blob/master/distributed_systems/life-beyoud-distributed-transactions-an-apostates-opinion.pdf?raw=true PowerPoint: http://blogs.msdn.com/b/pathelland/archive/2007/11/25/presentation-of-life-beyond-distributed-transactions-an-apostate-s-opinion-at-teched-emea-at-barcelona.aspx (Link unten auf der Seite) * Java Application Servers Are Dead: Slides: http://de.slideshare.net/ewolff/java-application-servers-are-dead Artikel: http://jaxenter.com/java-application-servers-dead-1-111928.html und http://jaxenter.com/java-application-servers-dead-112186.html
More Related Content
More from Lutz Hühnken
More from Lutz Hühnken(10)
Recently uploaded
Recently uploaded(20)
Be Reactive! at Functional and Reactive Programmers Group, Kaiserslautern March 31 2015
- 1. Be Reactive!
- 7. Be Reactive! SUG KL March 2015 Elastic • Ability to scale, but also • be efficient, leverage modern multi- / many-core hardware • Scale up and down - Clusters need to support joining and leaving of nodes • To scale, every part must scale - no single point of failure, no contention 7
- 8. Be Reactive! SUG KL March 2015 Resilient • Failure is embraced as a regular state in the system • Resilience is a first-class concept in your software • Failure is detected, isolated, and managed • Applications can recover from failure of parts (self-heal) 8
- 9. Be Reactive! SUG KL March 2015 Before we get to message-driven • Let’s talk about • Multi-Threading • I/O • Distribution • Deployment 9
- 10. Threads vs. task level concurrency
- 11. Be Reactive! SUG KL March 2015 A supposedly great idea • Threads are • lightweight processes • easier programming model, no IPC 11
- 12. Be Reactive! SUG KL March 2015 Lightweight? 12 Slide stolen from John Rose, Java VM Architect, JFokus, Stockholm, February 2015
- 13. Be Reactive! SUG KL March 2015 The problem with Threads 13 They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism.
- 15. Be Reactive! SUG KL March 2015 Threads • not efficient • memory consumption • cost for context switch • shared memory bad for modern NUMA architectures • locks lead to contention • not a good programming model • shared mutual state is difficult to reason about 15
- 16. Be Reactive! SUG KL March 2015 Tasks Better • task level (sub-thread) concurrency • share nothing approach • # threads ~ # of cores • Example: Actors, Play Actions 16
- 17. Blocking vs. non-blocking I/O
- 18. Be Reactive! SUG KL March 2015 High concurrency matters 18 But there’s one thing we can all agree on: At high levels of concurrency (thousands of connections) your server needs to go to asynchronous non-blocking. [..] any part of your server code blocks you’re going to need a thread. And at these levels of concurrency, you can’t go creating threads for every connection. From https://strongloop.com/strongblog/node-js-is-faster-than-java/
- 19. Be Reactive! SUG KL March 2015 Blocking I/O, Thread-per-request 19 From https://strongloop.com/strongblog/node-js-is-faster-than-java/
- 20. Be Reactive! SUG KL March 2015 Non-blocking I/O 20 Note: Single Thread is crazy! What about your other cores?
- 21. Be Reactive! SUG KL March 2015 Non-blocking 21 For task level (sub-thread level) concurrency • each thread is responsible for n tasks • and that n might be pretty big You don’t want to block such a thread with blocking I/O What if you must? Separate!
- 22. Distributed Transactions vs. EC
- 23. Be Reactive! SUG KL March 2015 Life beyond Distributed Transactions 23 In general, application developers simply do not implement large scalable applications assuming distributed transactions. When they attempt to use distributed transactions, the projects founder because the performance costs and fragility make them impractical. [..] Instead, applications are built using different techniques which do not provide the same transactional guarantees but still meet the needs of their businesses.
- 24. 24 Want Almost-Infinite Scaling • More of everything… Year by year, bigger and bigger • If it fits on your machines, multiply by 10, if that fits, multiply by 1000… • Strive to scale almost linearly (N log N for some big log). Assumptions (Don’t Have to Prove These… Just Plain Believe Them) Grown-Ups Don’t Use Distributed Transactions •The apps using distributed transactions become too fragile… • Let’s just consider local transactions. ! Multiple disjoint scopes of serializability Want Scale-Agnostic Apps • Two layers to the application: scale-agnostic and scale-aware • Consider scale-agnostic API Scale Agnostic Code Scale-Aware-Code Application Upper Layer Lower Layer Scale Agnostic API
- 25. Be Reactive! SUG KL March 2015 Distributed Transactions 25 Distributed Transactions („2PC“) are a source of unnecessary failure and of contention. It can usually be avoided. In the aforementioned paper by Pat Helland, he shows how to use local transactions and at-least-once delivery instead. The data storage landscape is changing, moving towards event sourcing and immutability. This is a great match for reactive systems.
- 26. App Servers vs. Containerless
- 27. Be Reactive! SUG KL March 2015 27
- 28. Be Reactive! SUG KL March 2015 28
- 29. Be Reactive! SUG KL March 2015 Java EE Application Servers 29 Servlet API was developed for thread-per-request, synchronous I/O. Application servers are not of much use anyway, nobody uses them as containers for multiple applications. Go containerless.
- 30. Summary
- 31. Be Reactive! SUG KL March 2015 Checklist 31 If • Threads are the smallest unit of concurrency in your code, or • You use blocking I/O (without clear separation), or • You use 2-phase-commit across systems, or • You run in a Java EE Application Server Then your application is not reactive.
- 32. Be Reactive! SUG KL March 2015 Want list 32 • Task-level (sub-thread level) concurrency • Non-blocking I/O • Distribution • Containerless Bonus: A simple, unified programming model
- 33. .. gives you all that
- 34. Be Reactive! SUG KL March 2015 Message-Driven • Loosely coupled architecture, easier to extend, maintain, evolve • Asynchronous and non-blocking • Concurrent by design, immutable state • Lower latency and higher throughput 34
- 37. Go Reactive! Swisscom March 2015 37
- 38. Go Reactive! Swisscom March 2015 • We want to be asynchronous and non-blocking • We need to ensure that our data is protected without locks • We want to compose individual tasks into broader business logic • Functional programming is critical to meeting these needs • Declarative • Immutable • Referentially transparent • Pure functions that only have inputs and outputs 38 Functional programming is key
- 39. Be Reactive! SUG KL March 2015 Where can I find that? 39
- 40. Be Reactive! SUG KL March 2015 40 Want to learn more? http://www.typesafe.com http://go.typesafe.com Questions? lutz.huehnken@typesafe.com @lutzhuehnken on Twitter