CONCURRENCY
                              IN
                           PLAY 2.0
                            Ola Wiberg




Wednesday, 11 July, 12
OVERVIEW

    • Background

    • Play         architecture

    • Integrated Akka

    • API

    • Asynchronous           IO


Wednesday, 11 July, 12
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
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
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
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
Java EE compared to Play
Wednesday, 11 July, 12
Play framework stack
Wednesday, 11 July, 12
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
Wednesday, 11 July, 12
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
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
CREATE AN ACTOR
                            Built in ActorSystem




Wednesday, 11 July, 12
USING AN ACTOR




Wednesday, 11 July, 12
CREATE AN ACTOR SYSTEM




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




Wednesday, 11 July, 12
HELPER METHOD




Wednesday, 11 July, 12
CALLING A WEB SERVICE




Wednesday, 11 July, 12
REQUEST => RESPONSE




Wednesday, 11 July, 12
What type of request, stream or regular request?
Wednesday, 11 July, 12
In-memory request
Wednesday, 11 July, 12
Stream/socket based request
Wednesday, 11 July, 12
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
Example System Overview
Wednesday, 11 July, 12
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
THANK YOU!

                            @OlaWiberg

                         olawiberg@gmail.com




Wednesday, 11 July, 12

Play concurrency

  • 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 comparedto Play Wednesday, 11 July, 12
  • 8.
  • 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.
  • 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 USEAKKA • 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.
  • 15.
    CREATE AN ACTORSYSTEM Wednesday, 11 July, 12
  • 16.
    EXECUTE A TASK Without creating an Actor Wednesday, 11 July, 12
  • 17.
  • 18.
    CALLING A WEBSERVICE Wednesday, 11 July, 12
  • 19.
  • 20.
    What type ofrequest, stream or regular request? Wednesday, 11 July, 12
  • 21.
  • 22.
  • 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.
  • 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