Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introduction to Vert.x

Horacio Gonzalez
September 18, 2014

Introduction to Vert.x

Horacio Gonzalez

September 18, 2014

More Decks by Horacio Gonzalez

Other Decks in Technology


  1. Horacio Gonzalez Spaniard lost in Brittany, Java developer, dreamer and

    all-around geek • Senior Software Engineer at Cityzen Data ◦ Cityzen Data provides a scalable, secure, ethical and open platform for sensor data • Co-founder & co-leader of FinistJUG & GDG Finistère http://lostinbrittany.org/ +Horacio.Gonzalez @LostInBrittany
  2. The old one thread per connection model... • Limitation to

    number of concurrent users ◦ Threads are a scarce resource • Non-efficient use of resources ◦ Lots of time spent idly waiting • High charges ask for lots of servers ◦ Infrastructure management problems...
  3. The old one thread per connection model... Connection Request 1

    Request 3 Request 2 Thread 1 Thread 2 Thread 3 Waiting time
  4. And the mobile web happened More and more users Users

    using the Web on mobility More and more device types
  5. The Reactive Manifesto Reactive Systems are: • Responsive • Resilient

    • Elastic • Message-driven http://www.reactivemanifesto.org/
  6. A different approach was needed • Asynchronous model ◦ Not

    only non-blocking IO ◦ Every potentially blocking task must be asynchronous • Event/message driven programming
  7. A different approach was needed • Event-loop ◦ A lone

    thread waits for data/jobs ◦ It dispatches tasks to thread to do them • Reactor pattern
  8. Nginx vs Apache HTTPD Nginx is event-driven and asynchronous Apache

    relies on processes and threads Apache is like Microsoft Word, it has a million options but you only need six. Nginx does those six things, and it does five of them 50 times faster than Apache. Chris Lea on Nginx and Wordpress
  9. In 2008 the unthinkable happened... • A fully asynchronous platform,

    build on an event- driven, non-blocking I/O model • And built in JavaScript!
  10. Node is great… but it has some problems 1. JavaScript

    2. Vertical scaling 3. Interprocess communication 4. Event loop
  11. Problem #2: Vertical scaling • A single instance of Node

    runs in a single thread ◦ To scale vertically you must spawn a cluster var cluster = require('cluster'); var http = require('http'); var numCPUs = require('os').cpus().length; if (cluster.isMaster) { // Fork workers. for (var i = 0; i < numCPUs; i++) { cluster.fork(); } cluster.on('exit', function(worker, code, signal) { console.log('worker ' + worker.process.pid + ' died'); }); } else { // Workers can share any TCP connection // In this case its a HTTP server http.createServer(function(req, res) { res.writeHead(200); res.end("hello world\n"); }).listen(8000); }
  12. Problem #3: Interprocess communication How do two Node process communicate?

    Lots of options (TCP, UDP, sockets, MQ, Redis pub/sub…) None simple and fully integrated
  13. Problem #4: Event loop In Node there is a single

    event loop everything runs on it! It must not be blocked!
  14. Answers to problems on Node • Problem #1: JavaScript ◦

    Polyglot API • Problem #2: Vertical scaling ◦ Built on JVM, naturally multi-threaded • Problem #3: Interprocess communication ◦ Event bus and native clustering • Problem #4: Event-loop ◦ Multi-reactor and worker verticles
  15. Vert.x under the hood • Written in Java • Built

    on NIO 2, Netty and Hazelcast ◦ Java 7+ • Polyglot bindings ◦ JavaScript, Groovy, Scala, Clojure, Ruby • Based on an extended reactor pattern: multi-reactor
  16. Verticles: packages of code executed by Vert.x JVM Vert.x instance

    Event Loop Workers Verticle 1 Verticle 2 Verticle 3 Verticle 4 Worker 1 Worker 2 Worker 3 JVM Vert.x instance Event Loop Workers Verticle 1 Verticle 2 Verticle 5 Verticle 6 Worker 2 Worker 4 Worker 5 Distributed Event Bus
  17. Verticles: packages of code executed by Vert.x • Many verticles

    can be executing concurrently in the same Vert.x instance • An application might be composed of ◦ multiple verticles ◦ deployed on different Vert.x instances ◦ communicating over the Vert.x event bus.
  18. Vert.x instances • Verticles run inside a Vert.x instance •

    A single Vert.x instance runs inside its own JVM instance • There can be many verticles running inside a single Vert.x instance • There can be many Vert.x instances ◦ running on the same host, or on different hosts ◦ configured to cluster with each other ▪ distributed event bus
  19. Easy concurrency • A verticle instance is never executed by

    more than one thread concurrently ◦ You can program all your code as single threaded • Different verticle instances ◦ exchange messages over the event bus ◦ share data on immutable shared maps and sets • Actor-like model ◦ Verticles - Actors
  20. Asynchronous Programming Model • Asynchronous core APIs ◦ Programming by

    setting event handlers • Able to handle many verticles using a small number of operating system threads (event loop threads) ◦ Vert.x sets the number of threads to the number of available cores
  21. Event loops • Loop while waiting for events, then deliver

    them to the handlers ◦ Example of event: data read from a socket, timer fired, HTTP response ended… • Each verticle is assigned to an event loop thread ◦ The same from deployment to server stop • Multi-reactor pattern Golden rule: never block the event loop!
  22. Worker verticles • When you need to perform blocking operations

    ◦ E.g. computationally intensive operations or JDBC connections • Worker verticles not assigned to event loop threads ◦ Worker verticles executes in threads from the worker pool ◦ Worker verticles can be executed concurrently by several threads ▪ Not concurrency-safe • They doesn't scale well ◦ Use them only when unavoidable Hybrid threading model
  23. Core API Provides functionality for: • TCP/SSL servers and clients

    • HTTP/HTTPS servers and clients • WebSockets servers and clients • The distributed event bus • Periodic and one-off timers • Buffers • Flow control • File-system access • Shared map and sets • Accessing configuration • SockJS
  24. Container API Provides functionality for: • Deploy and undeploy verticles

    • Deploy and undeploy modules • Retrieve verticle configuration • Logging
  25. Polyglot - web server in Java Run it: vertx run

    Server.java note no compile is needed! import org.vertx.java.core. Handler; import org.vertx.java.core.http. HttpServerRequest ; import org.vertx.java.platform. Verticle; public class Server extends Verticle { public void start() { vertx.createHttpServer().requestHandler( new Handler<HttpServerRequest >() { public void handle(HttpServerRequest req) { String file = req.path().equals( "/") ? "index.html" : req.path(); req.response().sendFile( "webroot/" + file); } }).listen( 8080); } }
  26. Polyglot - web server in JavaScript Run it: vertx run

    server.js var vertx = require('vertx'); vertx.createHttpServer().requestHandler( function(req) { var file = req.path() === '/' ? 'index.html' : req.path(); req.response.sendFile( 'webroot/' + file); }).listen(8080)
  27. Polyglot - web server in Groovy Run it: vertx run

    Server.groovy vertx.createHttpServer().requestHandler { req -> def file = req.uri == "/" ? "index.html" : req.uri req.response.sendFile "webroot/$file" }.listen(8080)
  28. Polyglot - web server in Python Run it: vertx run

    server.py import vertx server = vertx.create_http_server() @server.request_handler def request_handler(req): file = "index.html" if req.uri == "/" else req.uri req.response.send_file( "webroot/%s"%file) server.listen( 8080)
  29. A TCP echo server in Groovy A raw Groovy verticle:

    you can directly execute it Run it: vertx run Server.groovy note no compile is needed! To test it: telnet 1234 import static org.vertx.groovy.core.streams. Pump.createPump vertx.createNetServer().connectHandler { socket -> createPump(socket, socket).start() }.listen(1234)
  30. A TCP echo server in Groovy A compiled Groovy verticle

    Run it: vertx groovy:examples.EchoServer To test it: telnet 1234 package examples import org.vertx.groovy.platform. Verticle import static org.vertx.groovy.core.streams. Pump.createPump import org.vertx.groovy.core. Vertx class EchoServer extends Verticle { def start() { vertx.createNetServer().connectHandler { socket -> createPump(socket, socket).start() }.listen( 1234) } def stop() { } }
  31. Modules • Applications composed of modules ◦ Modules can contain

    multiple verticles ▪ Potentially written in different languages ◦ Encapsulation and reuse ▪ Shared on classic repositories ▪ Registered in module registry • Eco-system managed by the community
  32. Structure of a module • Module: zip file ◦ contains

    the resources needed by the module ▪ class files, .java files, script files, jar files… • Identified by an owner, a name and a version com.cityzendata~testvertx~test~3.2
  33. File mod.json • Descriptor of the module ◦ description, licence,

    author, keywords, developers, homepage ▪ used in the module registry ◦ main: verticle to start (if module is runnable) ◦ worker: true if it's a worker module ◦ includes: comma-separated list of modules dependencies ◦ auto-redeploy, lang-impl, multi-threaded, preserve-cwd, resident, system, deploys...
  34. File mod.json { "description": "Cityzen Data vert.x test project ",

    "author": "Horacio Gonzalez ", "main": "groovy:com.cityzendata.test.verticle.Main ", "auto-redeploy" : true "includes": "com.acme.common-stuff-v1.0" }
  35. Module classpath and classloaders • Each module is given its

    own class loader ◦ Multiple instances of the same module (same name and version) share classloader ◦ Multiple versions of the same module have independent classloaders • Module classpath: ◦ The root of each module ◦ Any jar on libs directory
  36. Running a module vertx runmod com.cityzendata~testvertx~test~ 3.2 • You can

    run the module by it's identifiers • You can use directly the zip file vertx runzip com.cityzendata-testvertx-test- 3.2.zip
  37. The Event Bus • Allows verticles to communicate with each

    other ◦ Irrespective of language ◦ Irrespective of Vert.x instance ◦ Even client side JS running in a browser can use it Distributed peer-to-peer network spanning multiple server nodes and multiple browsers
  38. The Event Bus is simple • It basically involves: ◦

    Registering handlers ◦ Unregistering handlers ◦ Sending and publishing messages.
  39. Event bus: addressing and handlers • Addressing ◦ Messages are

    sent on the event bus to an address ▪ An address is any valid string • Handler ◦ A handler is a thing that receives messages from the bus ◦ Handlers are registered to addresses ▪ Different handlers can be registered at the same address ▪ A handler can be registered at different addresses.
  40. Event bus: sending and receiving Two communication types • Publish/Subscribe

    ◦ Messages are published to an address. ◦ All handlers registered at the address receive the message • Point to point ◦ Messages are sent to an address ◦ Only one of the handlers registered at that address receive it ▪ Round-robin ◦ With our without reply
  41. Event bus messages • Message body types: • boolean •

    byte[] • byte • char • double • float • int • long • short • java.lang.String • java.util.Map - representing a JSON object • org.vertx.java.groovy.buffer.Buffer
  42. The echo message verticle def myHandler = { message ->

    println "I received a message: ${message.body}" message.reply "Response!" // Reply to it } def eb = vertx.eventBus eb.registerHandler("test.address", myHandler) vertx.createHttpServer().requestHandler { request -> eb.send("test.address", "Message!") { message -> request.response.with { statusCode = 200 statusMessage = "Hi FinistJUG" chunked = true write("I received a response: ${message.body}\n") end() } } }.listen(8080)
  43. How do I deploy it? We chose the fat jar

    gradle fatJar The full Vert.x server is zipped inside the jar No repackaging, meesa isn't JarJar
  44. Some links: C10k problem and real-time Web • The C10k

    problem (original article) • Wikipedia - C10k problem • Ars Technica - Say hello to the real-time Web • MMOAsteroids • Nginx vs Apache