vert.x
Bartek Zdanowski
TouK
vert.x
@BartekZdanowski
Bartek Zdanowski
● developer @ TouK
● co-organizer of Confitura conference
● Warszawa JUG member
● father and husband :)
vert.x

what actually vert.x is?
vert.x
● what is the Problem?
○ number of mobile users raises from year to year*
■ 2,1 bln in 2012
■ 7 bln in 2018
○ number of intelligent devices raises
■ Internet of things - 30 bln in 2020!**
■ IPv6 is already ready for all of them

* http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats/b
** http://en.wikipedia.org/wiki/Internet_of_Things
vert.x
● what is the Problem?
○ Tomcat: 200 threads = 200 connections
○ rest of incoming connections must wait…
vert.x
● what is the Problem?
● 1 thread handles one task
○ if thread is waiting for job to finish, whole queue of
tasks waits
○ traditional synchronous approach
○ waiting for job to finish (loop!)
vert.x
● different approach!
○
○
○
○

1 task = series of events lousely coupled
asynchronous
event that informs that new job/data is waiting
program should release thread instead of waiting for
operation (I/O) to be finished
vert.x
● different approach!
● program must wait for data. But only one thread should
wait!

event

thread
vert.x
● different approach!
● program always should wait for data! but only one
thread should wait!

event

reactor

thread
vert.x
● how it’s done in vert.x?
○ multi-reactor pattern
○ thread pool equals to cores count
vert.x
● how it’s done in vert.x?
○
○
○
○
○
○

introduces asynchronous programming approach
event driven
distributed
scalable
thread safe
uses actor model
vert.x
● demo
vert.x
● thread safe? when?
class MyService {
public synchronized Result doSomething(Data data) {
//do some critical stuff
○
}
}
vert.x
● thread safe? when?
class MyService {
public synchronized Result doSomething(Data data) {
//do some critical stuff
}
}

● only when 1 thread!
vert.x
● thread safe? when?
○ each verticle instance is always executed by the
same thread from thrad pool
○ separated classloaders for each verticle instance
○ event bus separates threads
○ shared data: maps, sets
vert.x

Publisher

Publisher - subcriber
publish() //broadcast

EventBus

Subscriber1

Subscriber2
vert.x

Publisher

Publisher - subcriber
send() //point-to-point

EventBus

Subscriber1

Subscriber2
vert.x
● EventBus
○ publish() - all subscribers
○ send() - only one subscriber, round robin
○ queueing of messages to be delivered

● but
○ no acknowledgement
○ messages are stored in memory only - volatile
messages!
vert.x
● EventBus
○ distributed - cluster
○ can be spanned to web client side via SockJS
vert.x

Publisher

EventBus

cluster!
host1

Subscriber1

Subscriber2

host2

host3
vert.x
● how vert.x scales
○
○
○
○

many instances of one verticle
clustering (auto-magic!)
eventbus spans through all nodes of cluster
uses all available cores
vert.x
● other features
○ Polyglot
■ Java, JavaScript, CoffeeScript, Ruby, Python,
Groovy + Scala, Clojure and...PHP
○ modules + public repo
○ embedding vert.x in application
○ Nice Http server + Sockets
○ Filesystem API
vert.x
● Opponents?
● node.js! really?!

http://www.cubrid.org/blog/dev-platform/inside-vertx-comparison-with-nodejs/
vert.x
● Opponents?
● node.js! really?!

http://www.cubrid.org/blog/dev-platform/inside-vertx-comparison-with-nodejs/
vert.x
● To summarize
○
○
○
○
○

extremely scalable
thread safe and multithreaded
distributed eventbus
polyglot
ready for year 2020 - 30 bln of devices ;)
vert.x
vert.x on Raspberry Pi! Monitoring Jenkins builds!

http://touk.pl/blog/en/2013/09/30/our-build-lights-in-action/
vert.x

demo
vert.x

Thank you!

Vert.x - JDD 2013 (English)