CONCURRENCY IN

PLAY 2.0Ola 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

• One process/thread per request

• Resource intense / upper bound limit

• State is handled by the stack

• Requests handled in "isolation"

• Easy to track control flow

• Apache, Tomcat

• Single process for all requests

• Less resource intense

• State maintained in program

• Single event-loop, with event call-backs

• Difficult to track control flow

• Lighttp, Nodejs

BACKGROUNDThreads or Events

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 stackneeds 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 ACTORBuilt in ActorSystem

Wednesday, 11 July, 12

USING AN ACTOR

Wednesday, 11 July, 12

CREATE AN ACTOR SYSTEM

Wednesday, 11 July, 12

EXECUTE A TASKWithout 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

• 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!

Async IO

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