vert.xBartek Zdanowski

TouK

vert.x

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

@BartekZdanowski

what actually vert.x is?

vert.x

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

EventBus

Subscriber1 Subscriber2

Publisher - subcriberpublish() //broadcast

vert.x

Publisher

EventBus

Subscriber1 Subscriber2

Publisher - subcribersend() //point-to-point

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

Subscriber1 Subscriber2cluster!

host1 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/

demo

vert.x

Thank you!

vert.x