12. Let's not paint a “Rose Picture” on Async
❏ Potentially you can have:
❏ Memory Leaks
❏ Race Conditions
❏ Complex state Machines
❏ Callback Hells (Look NodeJS)
❏ Error Handler can be difficult (look RxJava)
14. Thread issues
❏ No Language has a great abstraction to model TIME.
❏ Deadlocks
❏ Race Conditions
❏ Memory Inconsistency Errors (shared State)
❏ Bugs & Troubleshooting Issues
22. Executors
❏ Safe if your code
is safe.
❏ Better
Abstraction then
Direct Threads.
❏ Don't forget to
shutdown.
23. Executors
❏ Less worries.
❏ Thread Management
❏ Works with Queues
❏ Your code still need to be
Thread SAFE.
❏ Create ONCE, re-use as
much as you can.
❏ Be Careful with “clone”.
33. Threads Exercise (with Java >= 8)
Constraints: You cannot use frameworks, only the
“things” you learned in this class. Use Java.
1. Build a concurrent program with prints the time table of 7 (7x1, 7x2,7x3... 7x10) all in parallel and when
it ends print the results in order.
2. Build a concurrent program which calculates the factorial from 1 to 200 in parallel. Print the results at
the end when all calculations are done.
3. Build a concurrent program that count words in a file wich has 10mb. The counting must happen in
parallel as well.
4. Design and code a Worker from sratch, you should have a Queue and manage threads for the user. You
cannot use frameworks on any high level features like Service Executors or Java Thread Pools - create your
own.
35. Reactive Stream
❏ Standard Async Stream Processing
❏ Non-Blocking back pressure
❏ Equivalent Reactive Stream -> JDK9 java.util.concurrent.Flow
❏ Handle Stream of Data Issues
❏ Resource Consumption (i.g: Flood of Fast Data)
❏ Right Async code in order to Handle multiple CPU Cores
❏ Governance or Stream Data Exchanges (avoid arbitrary
buffering)
https://www.reactive-streams.org/
37. Actors & Akka
❏ Mature Actor ecosystem based on Erlang / OTP
❏ “Simple” concurrent Distributed Systems
❏ Resilient By Design
❏ Implement Reactive Streams principles
❏ High Performance & Scalability
❏ Up to 50 million msg/sec on a single machine.
❏ Small memory footprint; ~2.5 million actors 1GB.
38. Actors Issues
❏ Actors Code Reuse is complicated.
❏ Not meant for all kinds of problems.
❏ Does not work well on a “PURE” RPC system. Since actors
systems are similar to state machines.
❏ Can be much more complex than regular service development.
❏ Testing is Painful (being improved) but still.
47. Actors Exercise (with Akka >= 2.6)
Constraints: You cannot use frameworks besides Akka,
you need to code with Scala >= 2.13
1. Build a Chat application Akka: No Ui is needed. You need to have Messages, ChatRooms, People and people
need to be able to be in multiple chat rooms at same time. Chat Rooms has a limit of 10 people.
2. Build a Chat application Akka - part 2: Enhance your chat application and now create an Admin role
where a user could become an Admin and be able to KICK any user from any chat room.
3. Build a Chat application Akka - part 3: Enhance your chat application and now create observability for the
system, you need to have live tracking of: Number of messages, Number of chat rooms, top 3 people who sends
more message, top 3 chat rooms with more messages. Provide a print operation for the users see the metrics.
3. Build a Chat application Akka - part 4: Enhance your chat application and now Expose operations via
REST interface(for this homework you can add more frameworks and libs).