1. CONCURRENCY
IN
PLAY 2.0
Ola Wiberg
Wednesday, 11 July, 12

2. OVERVIEW
• Background
• Play architecture
• Integrated Akka
• API
• Asynchronous IO
Wednesday, 11 July, 12

3. A PLATFORM FOR
THE FUTURE
"The web has evolved from
static to dynamic to real-time."
"Play is a framework for highly-scalable
real-time applications!"
Wednesday, 11 July, 12

4. DESIGN DECISIONS
• Designed for asynchronous HTTP
• Assumes that any request is long-lived (streams/sockets)
• Concurrency using Actors (Akka) instead of Threads
• Reactive (event based) model for IO
• Keep things simple!
Wednesday, 11 July, 12

5. BACKGROUND
Threads or Events
• One process/thread per request • Single process for all requests
• Resource intense / upper bound • Less resource intense
limit
• State maintained in program
• State is handled by the stack
• Single event-loop, with event
• Requests handled in "isolation" call-backs
• Easy to track control flow • Difficult to track control flow
• Apache, Tomcat • Lighttp, Nodejs
Wednesday, 11 July, 12

6. A BETTER SOLUTION
• Threads are good
• Events are good
• Why not make use of them both?
• To do it well the complete framework stack
needs to support it!
Wednesday, 11 July, 12

7. Java EE compared to Play
Wednesday, 11 July, 12

8. Play framework stack
Wednesday, 11 July, 12

9. PLAY CONCURRENCY
• Integrated support for Akka
• For concurrent, distributed, event-driven solutions
• Asynchronous IO (play specific)
• Reactive model using Iteratee IO
• Event driven, non-blocking IO (streams/sockets)
• Netty for HTTP
• Asynchronous event-driven framework (NIO)
• Stateless architecture
Wednesday, 11 July, 12

10. Wednesday, 11 July, 12

11. AKKA
• Akka is used internally for concurrency features in Play
• Built in ActorSystem to be used by the application
• play.api.libs.concurrent.Akka helper object
• Startup new ActorSystems
• Access remote ActorSystems
Wednesday, 11 July, 12

12. WHEN TO USE AKKA
• When executing long running tasks.
• Calculations, data crunching, long running queries.
• When accessing web services.
• When accessing remote ActorSystems.
• When scheduling tasks.
Wednesday, 11 July, 12

13. CREATE AN ACTOR
Built in ActorSystem
Wednesday, 11 July, 12

14. USING AN ACTOR
Wednesday, 11 July, 12

15. CREATE AN ACTOR SYSTEM
Wednesday, 11 July, 12

16. EXECUTE A TASK
Without creating an Actor
Wednesday, 11 July, 12

17. HELPER METHOD
Wednesday, 11 July, 12

18. CALLING A WEB SERVICE
Wednesday, 11 July, 12

19. REQUEST => RESPONSE
Wednesday, 11 July, 12

20. What type of request, stream or regular request?
Wednesday, 11 July, 12

21. In-memory request
Wednesday, 11 July, 12

22. Stream/socket based request
Wednesday, 11 July, 12

23. REACTIVE MODEL
Async IO
• Handling data streams reactively
• Remove IO stream limitation (Blocking, memory, threads)
• “React” to input only at a rate it is needed (no buffering)
• Implemented using Iteratees, Enumerators, Enumeratees
(Consumer/Producer Pattern)
• Topic for another presentation!
Wednesday, 11 July, 12

24. Example System Overview
Wednesday, 11 July, 12

25. SUMMARY
• Play 2.0 is implemented for high concurrency applications
• Play 2.0 has a simple API for concurrency features
• Play 2.0 is great for:
• high throughput, low memory usage
• many concurrent requests / socket connection
Wednesday, 11 July, 12

26. THANK YOU!
@OlaWiberg
olawiberg@gmail.com
Wednesday, 11 July, 12