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

Vert.x v3 - Voxxed Days Berlin 2016 edition

Vert.x v3 - Voxxed Days Berlin 2016 edition

Tweaked and refreshed :)

47969d3a306ab00ecd55dc0137d37463?s=128

Bartek Zdanowski

January 29, 2016
Tweet

Transcript

  1. vert.x v3 high performance polyglot application toolkit Bartek Zdanowski TouK

  2. Guten morgen! Bartek Zdanowski @bartekzdanowski 2

  3. Hello Berlin! developer @ vertx lover father and husband :)

    3
  4. vert.x 4 Invented by Tim Fox as Node.x June 2015

    - released v3
  5. vert.x buzzwords simple embeddable toolkit threadSafe concurrent asynchronous eventDriven reactive

    eventBus scalable polyglot 5
  6. vert.x buzzwords fun 6

  7. the problem 7

  8. the problem number of mobile users raises 2,1 bln in

    2012 -> 7 bln in 2018 Internet of things - 30 bln in 2020! IPv4 is exhausted IPv6 is already ready for all of them 8
  9. the problem traditional synchronous approach ▪ one thread handles one

    task ▪ thread is waiting for job to finish ▪ whole queue of tasks waits 9
  10. the problem traditional synchronous approach ▪ synchronous code ▪ scalability

    problem ▪ lots of threads ▪ concurrency that no-one understands ;) 10
  11. the problem 11 Tomcat: 200 threads = 200 connections rest

    of incoming connections must wait*… *okay, now you can do nonblocking in Tomcat https://tomcat.apache.org/tomcat-7.0-doc/aio.html
  12. the problem lots of served connections == lots of threads

    big thread pool == big waste of resources 12
  13. the problem lots of served connections == lots of threads

    big thread pool == big waste of resources 13 RESOURCE W ASTE!
  14. the problem 14 thread pools

  15. the problem 15 thread pools

  16. the problem big thread pools are evil synchronous code is

    even more evil concurrency is very hard synchronous == blocking 16
  17. the problem big thread pools are evil synchronous code is

    even more evil concurrency is very hard synchronous == blocking 17 RESOURCE WASTE!
  18. the solution 18

  19. the solution 19 thread pools

  20. the solution 20 1 task = series of loosely coupled

    events event that informs that new job/data is waiting
  21. the solution 21 program should release thread instead of waiting

    for operation (I/O) to be finished use non-blocking IO (NIO)
  22. the solution 22 asynchronous event driven

  23. the solution 23

  24. vert.x 24 dispatcher handlers thread pool reactor

  25. vert.x 25 handlers thread pool thread-1 handler 1 handler 2

  26. vert.x 26 very small thread pool actor like model

  27. some code 27

  28. 28 public class HelloVerticle extends AbstractVerticle { @Override public void

    start() { LoggerFactory.getLogger(getClass()).info( "Hello vert.x"); } }
  29. 29 public static final String CONSUMER_ADDRESS = "consumer.address"; public void

    start() { vertx.eventBus().consumer(CONSUMER_ADDRESS, new Handler<Message<String>>() { public void handle(Message<String> message) { logger.info("Got message:" + message.body()); } }); } //Java < 8
  30. 30 public static final String CONSUMER_ADDRESS = "consumer.address"; public void

    start() { vertx.eventBus().consumer(CONSUMER_ADDRESS, message -> { logger.info("Got message: " + message.body()); }); } //Java 8 Lambdas FTW!
  31. threadsafe code 31

  32. threadsafe 32 class MyService { public synchronized Result doSomething(Data data)

    { //do some critical stuff } }
  33. threadsafe only when one thread! 33 class MyService { public

    synchronized Result doSomething(Data data) { //do some critical stuff } }
  34. threadsafe particular verticle runs in one thread! 34

  35. 35 verticle

  36. 36 basic deployment unit actor-like model (akka similarity) always run

    in the same thread classloader isolated can have many instances verticle
  37. verticle threadsafe code ▪ verticle instance - always the same

    thread ▪ separated classloaders for each verticle instance 37
  38. verticle threadsafe code ▪ event bus separates threads ▪ shared

    data: maps, counters, locks 38
  39. 39 eventBus

  40. 40 eventBus

  41. 41 eventBus

  42. 42 eventBus server 1 server 2 server 3

  43. 43 eventBus server 1 webclient server 2 server 3

  44. 44 eventBus Publisher - subscriber publish() //broadcast like JMS Topics,

    no replying
  45. 45 eventBus p2p send() //point-to-point like JMS Queues, can reply

  46. 46 eventBus p2p send() //point-to-point like JMS Queues, can reply

    round robin
  47. 47 eventBus p2p send() //point-to-point like JMS Queues, can reply

    round robin
  48. 48 public void start() { getLogger().info("Broadcaster started"); vertx.setPeriodic(PERIOD_MS, timerID ->

    { getLogger().info("Broadcasting message " + counter); vertx.eventBus().publish(Consumer.CONSUMER_ADDRESS, "Message " + counter); counter++; }); } Broadcasting a message
  49. 49 public void start() { getLogger().info("Broadcaster started"); vertx.setPeriodic(PERIOD_MS, timerID ->

    { getLogger().info("Broadcasting message " + counter); vertx.eventBus().send(Consumer.CONSUMER_ADDRESS, "Message " + counter); counter++; }); } Sending a message p2p
  50. 50 public void start() { getLogger().info("Consumer started! " + hashCode());

    vertx.eventBus().consumer(CONSUMER_ADDRESS, message -> { getLogger().info("Received message: " + message.body()); }); } Consuming a message
  51. public void start() { getLogger().info("Consumer started! " + hashCode()); vertx.eventBus().consumer(CONSUMER_ADDRESS,

    message -> { getLogger().info("Received message: " + message.body()); message.reply("I got your message"); }); } 51 Consuming a message + replying
  52. 52 vert.x ecosystem

  53. 53 lightweight vert.x core extensions ▪ web ▪ data access

    (mongoDB, redis, JDBC) ▪ security (basic auth, jdbc auth, jwt, shiro) ▪ reactive (based on RxJava) ▪ others vert.x ecosystem
  54. 54 web server

  55. 55 web server ▪ vert.x core - very raw and

    basic HTTP server ▪ web server ext - neat path and content routing
  56. 56 vertx.createHttpServer().requestHandler( req -> { LOG.info(String.format("Got request [%s]", req.path())); switch

    (req.path()) { case "/" : req.response().end("Ok. Here's root"); break; case "/other": req.response().end("Other things..."); break; default: req.response().setStatusCode(404).end("Unknown resource!"); } }).listen(port) vert.x core - very raw and basic HTTP server
  57. 57 Router router = new RouterImpl(vertx); router.get("/users/:uid").handler( ctx -> {

    String id = ctx.request().getParam("uid"); JsonObject user = new JsonObject().put("id", id).put("name", "bartek"); ctx.response().end(user.encode()); }); HttpServer server = vertx.createHttpServer(); server.requestHandler(router::accept).listen(8080); web server ext - neat path and content routing
  58. 58 router.post("/some/post/path") router.put() router.get("/user/data").consumes("application/json") router.get("/user/data").consumes("text/html") router.get("/info").produces("text/html") router.get("/info").produces("text/plain") web server ext

    - content routing
  59. 59 benchmarking

  60. 60 benchmarking https://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=plaintext

  61. 61 vert.x vs akka

  62. verticles: ▪ are actor-like ▪ can be addressed ▪ can

    subscribe to many addresses ▪ can do processing jobs ▪ can send back content ▪ can have multiple instances of same class 62 vert.x vs akka
  63. how vert.x scales 63

  64. vertically ▪ verticle can have multiple instances ▪ each instance

    can have own processor core horizontally ▪ clustering - lot’s of nodes ▪ eventbus reaches all nodes 64 how vert.x scales
  65. polyglot 65

  66. ▪ java ▪ groovy ▪ javascript ▪ ruby ▪ ceylon

    ▪ ...more to come! 66 polyglot
  67. 67 puts "Ruby for the win!" eb = $vertx.event_bus() #

    Send a message every second $vertx.set_periodic(1000) { |v| puts "RUBY: sending Ruby message" eb.publish("producer.address", "Ruby shines!") } Ruby shines
  68. 68 var eb = vertx.eventBus(); eb.consumer("producer.address", function (message) { console.log("JAVASCRIPT:

    Received a message: " + message.body()); }); console.log("Receiver ready!"); For JavaScript dare devils!
  69. usecases 69

  70. ▪ effective use of servers’ resources ▪ parallel computing ▪

    great as a backend for lots of (mobile) clients ▪ nice integration platform ▪ could be awesome in microservices 70 usecases
  71. YOU getting started 71

  72. http://vertx.io/ https://github.com/vert-x3 https://github.com/zdanek/vertx-pres 72 YOU getting started

  73. grab a sticker! 73 YOU getting started

  74. have fun! 74 YOU getting started

  75. I’m not the owner of the pictures used. Just found

    them on: http://www.rantchic.com/wp-content/uploads/2013/12/Apollo-13.jpg http://www.gamesaktuell.de/screenshots/1280x1024/2009/04/terminator_2_blu_ray03.jpg http://tripoutlook.com/wp-content/uploads/2013/03/Car-parking.jpg http://upload.wikimedia.org/wikipedia/commons/5/52/Parallel_Parking_cars.jpg http://www.foreverbarcelona.com/wp-content/uploads/2014/02/Taxi-Tips.png http://www.125p.eu/wp-content/uploads/2009/03/fiat-125p-zmiennicy-5.jpg http://www.novosti.rs/upload/images/2011/07/2107/bg-taksi.jpg http://www.stadtentwicklung.berlin.de/verkehr/mobil/auto/pix/taxi_cb_470.jpg http://i.livescience.com/images/i/000/024/292/iFF/neurons-120208.jpg?1328727600 75 All the pics used
  76. 76 Danke schön!