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
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...
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
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); }
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
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.
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
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
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
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!
◦ 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
you can directly execute it Run it: vertx run Server.groovy note no compile is needed! To test it: telnet 127.0.0.1 1234 import static org.vertx.groovy.core.streams. Pump.createPump vertx.createNetServer().connectHandler { socket -> createPump(socket, socket).start() }.listen(1234)
multiple verticles ▪ Potentially written in different languages ◦ Encapsulation and reuse ▪ Shared on classic repositories ▪ Registered in module registry • Eco-system managed by the community
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
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...
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
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
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.
◦ 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
lostinbrittany
andpad
ufoo68
yoshikiiida
habakan
manabusakai
shuntaito
aar_nobu
masahirokawahara
tommy351
sansandsoc
tsukubachallenge
danielanewman
matthewcrist
jponch
andyhume
tenderlove
reverentgeek
philhawksworth
holman
pedronauck
shpigford
brianwarren
lauravandoore
