Vert.x: This ain't your Dad's Node.

so today we're going to talk about vertex and we've already heard several times that it is roughly the equivalent of node for the JVM and I just realized that I haven't started my slides so there they are so here are my details I'll also have those at the end I uploaded this deck to SlideShare this morning but it's been still processing for the last four hours so eventually it will be out there so before we get into vertex and and and node I always like to start with you know what problem is that that we're trying to solve and actually I want to to look at two so everyone familiar with the CIE 10k problem yes no maybe how do we deal with 10000 concurrent connections without the server falling down and going boom of course this has become especially pertinent in the last five years or so with the birth of our smart mobile devices and so very recently we actually passed the point where there are now more mobile devices connected to the Internet then there are PCs and this problem isn't going away so we have to start building application architectures that can handle that kind of concurrent load and the other problem you know most of us are familiar with this as well you know how do we build advanced server push features into apps how do we get data into the browser without having to constantly pull so we can build you know these quote-unquote you know rich internet applications to turn this bin you know do you beaten to death can't considerably and so these were the types of questions that Ryan dollars are took me to deal with in 2008 2008 doesn't seem that long ago well let's go back in 2008 our existing frameworks platforms Frank very tightly coupled to this idea that you know servers something that receives a request and it spins up a thread to deal with it and then it sends back a response and all this of course happens sequentially well of course this was not web-scale now to be able to push vents to the browser the platform needs to be able to handle a lot of open connections that are mostly idle now Ryan's background in systems programming led him to create you know a small test environment that could handle thousands of idle connections and he did this using non blocking UNIX sockets and C but Ryan didn't want to work in C he wanted a higher-level language he wanted a higher level of abstraction in fact he wanted a dynamic language and I tend to agree with him I don't want to work at that low of a level either as it turns out life is entirely too short for malloc so about that same time would we get Doug Crockford published JavaScript the good parts and we started taking JavaScript more seriously you know it's not going anywhere it's the most you know really the only ubiquitous programming platform that we have for the web and Crockford showed us you know we can leverage the good parts of javascript while avoiding the ugly parts that get us into trouble then add further fuel to that fire was Google releasing Chrome in the v8 JavaScript engine and so the first time not only did we have you know a real technology competition going on a JavaScript space we had JavaScript going blazingly fast and now we start the arms race of browsers all over again and we have more players in the field you know we have Google and Apple and Mozilla and Microsoft all trying to outperform one another when it comes to JavaScript engine so you could bring these three things together and you know Ryan has this epiphany why don't we do non-blocking sockets in JavaScript and a few months later out pops node now as you say you've covered node none of you came to the node meeting it looks like so who's familiar with node doesn't he who's written serious code and node at all so so a couple of us so you can probably talk about node a lot better than I can I I can't go in-depth with node because I only learned enough node to make a reasonable useful comparison with vertex now from what I've learned I like it it's a solid piece of technology you use it intelligently you can build some very solid app architectures with it but no does have some shortcomings so we talked about JavaScript and a positive light a second ago let's talk about it in a negative light javascript has its problems we'll talk about some of those no does not really have a good story around vertical scaling horizontal scaling great vertical scaling hard inter-process communication also something that we can do but it requires a lot of low-level programming a lot of glue code a lot of bolting on of add-ons and then there's this event loop thing the event looks great unless you need to do work that doesn't fit on an event loop and that's a problem that we can't really solve so all these solutions that we have on the node they require a lot of legwork on our part and what vertex does is to take the same event-driven non-blocking i/o programming model that we got from node all the good stuff and then directly address all of those shortcomings so that you can spend your time working on your app and push all these concerns down into the framework so what I want to do is I want to walk through each of the problems and I want to show how vertex addresses those now you said you wanted me to ask questions for the giveaway so I've already decided how I'm going to do that so pay attention to the slides I'm not going to say probably any of the answers to the questions but they will be there so JavaScript you're going to write node programs you have to use JavaScript now yes we can write CoffeeScript and we can write closure script but the burden is on the developer of the language to get his or her code compiled down the JavaScript and then and only then does node pick up with it now javascript has some problems who's seen wet okay you guys have homework should go watch this if we had time I'd play it so javascript does a lot of weird implicit conversions we have still not a reasonably consistent way to do namespacing and organize large code bases in JavaScript now the Google closure tools have gone a long way to help us with that but at the end of the day there's still very little agreement on how do we structure really large JavaScript code bases of course we have this weird class like syntax coupled with decidedly not class-based inheritance its prototype abased and of course we it's just easy to do really bad things of course these aren't the only problems they have a Java Script but there's some of them so vertexes approach is polyglot programming use the right tool for the job now I've been talking about polyglot programming for a long time most of you are polyglot programmers you just don't consider yourself to be even if you use one core language if you're doing web development you're using several languages you know if you consider HTML CSS languages you throw JavaScript in there you throw in SQL or a query language for your check or persistence layer you're doing polyglot programming so vertex takes the approach of bringing in polyglot programming for the core language programming whatever language you want in fact feel free to mix and match multiple languages and vertex will take care of the communication between those so several languages have first-class support today let's do a hello world tour of the languages that are out there so here's how we do HelloWorld in Java so what we're doing is extending a vertical class I'm going to talk about what a vertical is a little bit later but suffice to say this is the unit of programming in vertex and we're going to be compelled to implement the start method so in the start method what are we doing we're doing the stereotypical nodejs hello world example we're spinning up an HTTP server we're providing it with a request Handler and all that request handler is going to do is write out hello world to the response and we're listening on port 8080 so this is what it looks like in Java now the code gets a lot smaller and all the other languages in movie this is what we have doing exactly the same thing now notice that we're moving between languages but the AAPI is consistent between them if you can expect a method in Java you can expect it in groovy you can expect it in Ruby now Ruby is leveraging JRuby under the hood to run on top of the vertex in the JVM but again essentially we have the same programming model with Ruby syntax and Ruby constructs we can also do this in Python again same constructs and of course if you're a node programmer wanting to jump on to the JVM you can write JavaScript and the JavaScript code that you start to write in vertex looks very familiar very comfortable in terms of what you're used to writing when you're doing no code and of course we also have first-class CoffeeScript support that's been added fairly recently CoffeeScript and Python or the newest kids on the block now in the future we have some fledgling Scala support that's that's become available it's not really first class yet a couple of us are starting to have conversations about adding closure support to vertex theoretically any language that'll run on the JVM or any language that will compile down to a supported language so maybe we could take the closure script to JavaScript to vertex route as well these are different things that we can do so now that we've examined the language issue let's take a look at second problem vertical scaling so nodejs instances are inherently single threaded why because v8 itself is inherently single threaded from the perspective the program now there are ways around that but they involve low-level hacking and as I was telling some folks earlier if order for me to solve my problems I don't want to go lower down the stack I want to go further up the stack I want to work at higher level abstractions not lower level extractions and so anything that the platform can give me to allow me to stay up here thinking about my application and not be down in the weeds this is something that I'm interested in and so the implication here is if I'm writing node programs my code is going to use at most one core on my server of course the node.js folks recognized this and added the capability to fork child processes and to support load balancing across those processes they created the cluster module now the cluster module depending on who you talk to is a good thing or a bad thing if you look at the official documentation it's still considered experimental but there are no shortage of Stack Overflow questions saying yeah yeah just use cluster just use cluster everything will be okay well let's go that route so there's a book actually a few books now on node and one of the earliest books is called node up and running it with a shortcut style books from O'Reilly and get into Chapter three they start showing this example of how to use cluster to distribute the work of hello world across several nodejs processes and so this is kind of the Minimum Viable code that you would need to write in order to vertically scale hello world on nodejs using cluster now who's doing the work here you are there's an API there that you can leverage but the end of the day using that API correctly the burden is upon you to make this code work properly and to get all the glue in the right places to make things happen now obviously this is hello world it gets a lot more complicated than this and if you continue to read the next four pages of the book the code gets much more complex very quickly as they add additional monitoring and management features to a again hello world app so what we end up with if we're not extremely careful is a ton of glue code intermingled where our application functionality now who like that no I like to have my application functionality I like to be able to look at my domain concepts see them clearly expressed and then all of the ancillary concerns the cross-cutting concerns I want those push down into the framework of the platform that I'm programming with so vertex leverages the built-in mature threading capabilities of the JVM to make vertical scaling trivial so again meet the vertical what did vertical come from think atomic particle except for vertex that's where the name came from we have some interesting ways of naming things not to be confused with vertical as in vertical scaling up and so we've got some terms that aren't confusing here for a little bit so vertical unit of deployment so any vertex instance any virtue I'm sorry any vertex application is going to be composed of one or more of these verticals verticals nothing more than the Java classes that we looked at or scripts that we looked at in the hello world section so if you write these you're gonna be writing verticals so a vertex instance is a JVM process that is running the vertex engine if you will vertex engine consists of several threads so we're concerned here primarily with a group of threads that provide us with event loops so again we're starting to see one of the first differences node one event loop vertex many event loops how many well it checks to see how many processor cores you have available using runtime about available processors and it's going to create an event loop thread for each one of those and then verticals are assigned to an event loop thread if I run vertex with the command line argument instances and I give it a value equal to the number of cores you're gonna see the vertical automatically scaled out to one instance per quart of course we can run more instances than we have course because each instance is typically not going to be able to keep the core busy all by itself now what does this bring up we don't like to talk about this word yeah concurrency we've got multiple threads in place so how does vertex deal with concurrency we don't to think about concurrency when we're in the JavaScript world because we just have a single thread so now all of a sudden all these problems get dumped in our lap well hold on so as we said each vertical instance is assigned a thread slash event loop you can kind of think of them the same way that vertical instance is guaranteed to always execute on its assign thread it will never execute on any other threat so once it gets that thread assignment it's always running there never anywhere else now a thread may execute multiple verticals but the same vertical instance will never have its work done by another threat furthermore the class loaders for the verticals are isolated and that prevents them from sharing global state with static members global variables and other things so all of these constraints give us the ability to write all of our code and I should have been going through points here to write all of our code assuming single thread II you know there's no need to worry about synchronization there's no need to worry about locking of course now that we've you know guaranteed that our verticals are isolated we have a problem we've got a bunch of processes out there running that are isolated they can't talk to each other we can't get any useful work done so nodes faced with the same problem so now we actually have two problems to consider how do we get nodejs processes to communicate with each other as we know we can fork them we know we can cluster them how do we get them to talk how do we get vertex verticals to communicate with each other because it looks like we've created this walled garden where every single vertical is unable to communicate with another well in the nodejs world you spend some time googling about searching and you run into a lot of solutions a lot of solutions some of which make me scratch my had some of which seemed okay but maybe not so much so we're the first things that comes up is we you just need to learn socket programming you know you need to start learning teasing you know using TCP UDP UNIX sockets and this is how you get your processes to communicate now what do we just get done talking about we don't want to be down there we want to be up here at a higher level of abstraction so that we can focus on our app and not focus on this low-level stuff also Redis pub/sub okay that makes a little bit more sense so I need to figure out how to you know there's of course there's options out there that make it easy to talk to Redis but I need to learn that maybe I don't know Redis we need to bring that into my app and get that done 0 mq this helps a little bit we're still dealing with sockets but we're dealing with a higher level of abstraction over plain sockets so that's getting better some other solutions just say oh well you know there's some built-in messaging in cluster that you can use not very full-featured you can use process signaling again down in the weeds and there are also various eventing frameworks out there that transcend processes that we can work with the one that seems to be the most popular is called hook IO I it's dead and from what I could tell there was some interesting political play that went on there but you know if you try to go to any pages other than the legacy mailing list for it you can't find anything and there's others like Jay s signals and beam and these look ok you can do shared memory with memcache that's also an option what do all of these things have in common well they all require me to hook into some third party technology that you may or may not want to add to your stack or and/or they require a great deal of low-level programming something that I've also said I don't want to do so two solutions that vertex provides us the first is the event bus the event bus is what we like to call the nervous system of vertex it is a cross-cutting abstraction that's built on the platform so it's built-in you don't have to go get anything to install it it's not an add-on it's part of the core it allows us to sin and receive transient messages through the out throughout the application not persistent messages if you want them to be persistent you need to hook into more of a persistent work queue work queue manager that we do have some add-ons that are starting to grow up within the add-on module community but this is not available so transient messages if your app dies your messages are gone let's assume it's up this allows the verticals to communicate with each other irrespective of what language they're written in whether or not they're in the same vertex instance maybe they're in different instances and it even allows client-side JavaScript running in the browser to communicate on the same bus more on that later so messages are sent on the event bus to an address vertex doesn't bother with any fancy schemes for addresses simply a stream any strings valid it is why is to use some kind of a name spacing scheme to keep things organized so you know something like messages dot inbound a something that makes sense to you to kind of keep things making sense as the application grows so a handler is what a thing that receives messages from the bus now we have handlers in vertex for just standard programming such you know we have HTTP request handlers we have TCP request handlers but we also have handlers that are specifically involved in working with the event bus so you register a handler at an address this handler can be in any vertical or any instance of a vertical so we could be running multiple vertex instances on the same box more likely we would run multiple vertex instances on multiple boxes and then we can use hazel cast to work with these I'm sorry can you say the last part one more time so the question is how do we coordinate the communication across vertex instances on different machines how do we get them on the same event bus I'm actually going to bring that up a little bit later but I'll go ahead and say it now the there is a cluster mode that is built into vertex it's actually leveraging hazel cast to cluster the JVM instances and that right now that's restricted to the event bus but we'll see some more features coming out around that as vertexes continues to move forward other things about handlers we can have multiple handlers registered in a single address so I can have multiple pieces of code that are interested in receiving messages that are directed to a particular address I can also have a single handler registered at multiple addresses and so I can have one address that I can have a single handler that knows how to deal with different types of messages that are coming to different locations how do I register a handler so we're gonna do most of the examples in Java code so here basically we're going to get the event bus object from the vertex object vertex object is available to you whenever you extend and vertical and then we have a handler interface we're going to implement an anonymous handler here and basically all it's going to do is print out a message based on the message body and then we register that handler at the address it's as simple as that now we support multiple styles of messaging in vertex so of course we have pub/sub deliver a single message to all handlers registered at an address that makes sense how do we do that well it makes sense we have a published method that takes an address and takes a message and sends that to that address and then all of the handlers that are registered there will receive it we also have point-to-point messaging with point-to-point it's going to deliver to at most one handler that's registered at an address it uses non-strict round-robin load-balancing and optionally you can specify a reply a reply handler you have a reply handler that reply handler can have it its own reply handler and you can have sort of a two-way communication process going on between message handlers so when we do p2p we're going to do it with the send method yes he so you just did something very naughty so you guys so that so the question was how do you you know if you're dealing with round-robin you've got one processor over here that's involved in a long-running job and so we want to notice that load and not send the requests that direction well again you think load a long-running job you think blocking work when you think blocking work you think no this can't run on the event bus or the event again but you don't want to do that on an event loop that's one of the problems with node is you and it's been a discussion that we've had for a very long time and the community as I've observed is that when we're doing things on an event loop what happens when you block for a long period of time processing something on the event loop the app stops nobody else can get request now vertex deals with this I'm not gonna deal with it in this section but if you hold on a few minutes we'll actually get to that specific solution because this is a big problem that vertex attempts to to address okay so we're doing point-to-point messaging we can just do a sindh we can do a fire-and-forget but we can also do a reply request reply model so the way we do that I've got the sender and the receiver code here so the sender and get my slide here is very small so I'm gonna look up here to read it to you so our send method we haven't address we have a message and we're going to address add to the last argument here a handler that handler is specifically there for a reply handler so we have some methods do not do not take a handler they just send they give the message and it's gone here we're going to expect a reply the receiver is going to handle the message and then on the message object itself it has a reply method where it can send a reply that reply will go back to the original sender and will be handled by that reply handler that we see in the top section of code now that one could also reply and we could have two-way communication going back and forth as much as we desired now this is one part of the API that differs a little bit from language to language and we'll see an example of that when we get into some JavaScript code towards the end but for the most part even if the API in terms of the mechanics of using it if they differ a little bit the concepts are for the most part all present so message types what kind of stuff can we send around well we can send around strings primitives box primitives buoy ins we can also send around JSON objects in fact JSON is one of the preferred communication mechanisms for vertex reason why almost all of the languages that we work in with the exception of Java have very nice very easy semantics for dealing with json data with java we actually have this JSON object that we work with specifically for vertex question in the back ok and then we also have buffers and I'll touch on buffers a little bit later on so again we said we can distribute vertex so here we have again three instances of vertex all running several verticals and we have a single event bus that spans all of them and we deal with that using hazel casts so I'm not going to go through the API for that right now it's really not an API there's just some command line argument so we're gonna pass and also some configuration files that we could edit and basically set up our clustering where one node becomes the kind of the orchestrator of the cluster and the other nodes for the most part become slaves but all of that is configuration runs under the hood when you're in your code writing your code you don't have to think about whether my vertical is running on this node versus this node versus this node all of that stuff essentially just works I think yeah in the back what are we using for JSON support in in the Java code specifically so so vertex so Tim when he implemented vertex he implemented his own set of JSON object support and then the the other languages for the most part we're just using the built-in support for JSON yes yes yes so the question is ultimately you know what are we using is the underlying communication mechanism almost all the communications being done through nioh - which of course means that we require Java 7 for vertex so you're not running Java 7 you're not running vertex do I have to have a configuration file for vertex in general or for the clustering yes there is a cluster config file and if we had some if we have some time at the end I can pull it up it's not very fancy or exciting it's just configuration for hazel caste so something that's somewhat unique to vertex is that we can also using the same programming model we can go into the browser and so using Sauk Jas vertex implements what's called an event bus bridge that allows you to have code running on the server interacting with code running within the browser using the same event bus programming model so what might this look like so on the server side here where again we're creating an HTTP server and we're setting up a basic request handler that's just going to serve up two files on index dot HTML file and then the very important vertex bus J s so if in your app you want you write code that uses the eventbus in the browser you will have to include this you also have to include Sauk Jas in your application and then we're gonna create a sock Jas server so vertex has a full implementation of the sock jeaious API I'm going to create that server and then we're going to create a bridge and we're configuring the bridge here and what we've done is we've told it three things what prefix do I want you to send a request to and so when I go try to communicate with the event bus I'm going to be making HTTP request to slash event bus and then I'm also dealing with another problem I've got this sock j/s bridge out there now so theoretically any browser that can hit my URL can send messages and in my system that's bad and this is still bad because what we've done we've got two arguments here one says what types of incoming connections am I going to allow what types of outgoing connections am I going to allow and here I've given it a blank array with a single blank object and it says allow everything this is a demo listening on 8080 so client code what does that look like so in the client side we've got our sock genus we've got our vertex bus we're going to get a handle to the vertex of it bus again through the vertex object look it looks exactly like the server-side code and then we're going to say on open so we have some events that we can listen for on open means okay the event bus is initialized and ready I want you to register a handler and basically what I want you to do is echo back any message that I receive so now let's talk about another way of communicating or sharing information between processes and that's share an immutable state now why do I have Ricky up here because we're chickies all about immutability and values and so I thought he was a good person to carry this forward so what if we wanted to manage and in-memory web cash could we do that with message-passing in the event bus well we want the app to scale across all available cores modeling this using message passing is problematic at one end of the scale you could have a single vertical that manages the cache but that means that all requests to the cache are going to have to be serialized through a single threaded instance and we've lost our vertical scalability that we wanted now we can improve that by having multiple instances of the vertical managing different parts of the cache but that starts to get very ugly and complicated really quickly so we really don't want to do this with message passing it's not a good fit for the problem now we said shared state is dangerous and we prevent a lot of shared state in vertex out of the box to make it easy to assume a single threaded programming model but as it turns out shared state is only dangerous if it's mutable in fact go back to effective Java that you know the book that's been around since we've been doing Java programming for the most part it tells us that if a muted data is immutable it can be shared freely and in fact such sharing is encouraged and we want to make that easy to do and so vertex actually has a shared data object that is part of the platform that allows us to work with a couple of different shared data stores first of all we have a collection of Java util concurrent concurrent Maps and so I can create a map out there it's a concurrent map supports atomic updates and I can put immutable data into that map and that map will be visible to all of my vertex instances I'm sorry all of my verticals I need to speak correctly we also manage a set a collection of Java util sets as it turns out these sets are also backed by a concurrent map so the same underlying infrastructure going on there elements need to be immutable values so we'll get into that and currently this is only available within a vertex instance so a single JVM process right now if I have a cluster I cannot share data across multiple clusters I mean I cross multiple instances within a cluster this is planned hazal cast supports this type of stuff and so it's just a matter of it actually being implemented and tested and put into a release question yeah so so the question I think the question is if I've got objects out there that are immutable that I've created but then I've got isolated class loading how does that work so basically what we're gonna have to do to make this happen is cheat so what are out what can we put in here actually if you drill down into the source code both of these data structures employ a type checker and they look at what's being pushed into the map or the set to ensure that it's a type that the concurrency model would actually support so we can put strings in there obviously they're immutable box primitives we can put byte arrays buffers again not going to talk about buffers tonight in short they are kind of a smart byte array so it's a sequence of 0 more bytes you can write to it you can read from it and it expands automatically as necessary to accommodate any additional bytes so it feels kind of like a vector or array list of bytes if you will if you actually use this it's going to be copied as it's shared between verticals so you never actually see the same instance and then we have this last caveat here any implementers of shareable this is how vertex JSON objects are able to be placed into the map what is shareable do nothing it's a marker it's a marker that carries the Javadoc that says if you slap this on a class it must be thread safe so danger if you're going to use this put it now what about the class loader isolation problem well as it turns out if I implement a class and I put on the system classpath then yes it is available across all of the verticals so if I have a custom class of my own that I want to implement I need to do a couple of a couple of things first of all I need to make sure it's thread safe second of all I need to make sure it implements shareable and third I need to get it on the system class path so again this is the you know the - CP arguments that I'm pushing to the Java process on startup so you do those three things you can share your own custom classes between the verticals so shared map so I've got two verticals here imagine that and one vertical I'm getting a map app cache if it doesn't exist it's gonna create that map and give me back the instance and then I'm putting in the user ID 42 and another vertical I get the map back out and I get the value out of the cache shared set work similarly here we've got a set called app dot sessions we're gonna put a session UUID in there and then in the other vertical I'm going to get the sessions out loop through them and do something useful with them so this is kind of the extent of the shared data capabilities that we have today so again so between processes we've got a couple of good stories now I can do message passing on the one hand where that makes sense I can do shared data on the other hand where that makes sense so both of these available to you out of the box in the framework allowing you to do coordination between multiple processes very easily much more easily than you would be able to do using using node which brings us to the last problem the event loop this is the one I said that we couldn't solve at least we can't solve it in node easily so what is no no does the implementation of the reactor pattern what's the reactor pattern well reactor patterns got three main things there's a paper out there that you can read that goes into a great level of detail but at the end of the day it's what you've got an event loop you have an application registering handlers would the event loop in some way and then you've got events that happen that trigger those handlers and this is how all of the programming takes place something happens I listen to it I do something with it something else happens I listen to it you know it's swinging it's any kind of UI programming all different implementations of the reactor patterns so this is what we carried into nodejs so what do we know about the reactor pattern well we've got in node we have a single thread we have a single event loop can't really do anything about this now we can go hack v8 and there are actually projects out there that are hacking v8 to give you multiple threads in v8 if you want to do that knock yourself out I'd much rather go with a platform like the JVM that's kind of been working on this problem for several years and has you know gone to great lengths to get it right and again you want to go hack on v8 again you're going at an even lower level of abstraction than you were before what else do we know everything runs on it you run code and nodejs it's running on the event loop you must not block the event loop if you go out and calculate you know Fibonacci 1000 you go out and start doing prime number identification you go out and work with some legacy blocking API do image processing whatever it is while that's going on all those other requests that are coming into your process they're waiting because there's only one thread only one thing doing work at a time so what are the problems with that kind of a programming model well some work is just naturally blocking you know anytime you want to do intensive data if you want to process genome sequence data you want to process large graph networks you want to process big data all of these things they take time they take processor power and so these things are gonna block the event loop we're not going to be able to deal with threads also third party blocking API is you want to talk to a database over JDBC for example which you can't do that in node but similarly it's a blocking API JDP assume JDBC assumes I'm going to send a sequel query I'm gonna get back a response I'm gonna do something with it I'm gonna send another query I'm gonna get something back I'm gonna wait so anytime I've got IO going on any kind of got network traffic going on my processors just sitting there and doing nothing and it's also not doing anything you know with the other requests that are sitting there waiting so a pure reactor is just not a good fit for this kind of work so if the type of application you're building is very amenable to the asynchronous non-blocking i/o problem the node is an awesome fit for you you're in the sweet spot if you have a lot of this type of work node is not a good fit for you and people have gone crazy trying to make node work for that kind of scenario because everybody said that they had to use node and you know they ended up hurting themselves so solution here let's be pragmatic let's acknowledge that there are some types of work that it want to execute on event loops there are other types of work that don't and so vertex provides us with worker verticals so worker verticals they're not assigned a vertex event loop thread we're not going to put them on the event loop at all instead we're going to manage a background pool of threads that we call background threads and so I can flag any one of my verticals as a worker and instead of it going into one of the event loop threads that equals my number of processors it's going to go into that background thread pool just as with our regular verticals workers never execute concurrently on multiple threats so this gives us the same single threaded programming model in the workers that we get with the normal verticals however not allowed to use the TCP or HTTP non-blocking api s-- so we communicate with verticals just like we do any other vertical using the event bus you want to keep worker verticals to a minimum anytime you're using verticals worker verticals you're using them because you're doing something that's blocking well if your entire application is worker verticals and then you've got one non worker vertical that just normal vertical that services requests and then passes them off to the blocking API what have you done you've just reinvented the old programming model with a new toy so we want to keep these down so now we've got this complete picture of vertexes model of the reactor this is what the vertex team calls the multi reactor so we've got our event loop thread pool we've got our background thread pool we've got verticals assigned to the right positions and then all the communication is accomplished with the event bus so what does this look like so I said something about Fibonacci earlier so I've got this kind of toy example of a Fibonacci worker what does the Fibonacci worker do well it's going to get a hold of the event bus register a handler at the fib request address and when I get a message there I'm going to calculate that Fibonacci number and then I'm going to place the number that was requested in the result in a message and send that to the Fibonacci response address now in my what's called worker example this is my normal vertical again I'm getting the event bus I've got a result handler here that is going to handle responses from the fibonacci worker and I'm going to register that handler at the Fibonacci response address and then I have container a container is another variable object that's available to you when you extend Verta collé container has a deploy worker vertical method so when I do this it's going to take that and place it off of the event loop and put it in that background thread pool my arguments here the address I've got a configuration object that I can pass in different parameters I can specify the number of instances of the vertical here so if I put in 10 there I would have 10 of these guys and then I've got my handler that is just sending off the messages to the FIB request ok so let's go over the 4 again quickly and then we'll we'll do the fun little case study so nodejs compels us to use javascript or something that we can compile down to javascript vertex polyglot good you can use whatever language I want nodejs inherently single-threaded I can make this better but I have to bolt a bunch of things on I have to do a bunch of low-level glue code vertex leverages the JVM already multi-threaded makes it very easy for me to scale a single vertical across multiple threads nodejs doesn't help us at all out of the box with inter process communication there are different options out there that we can leverage you got to go bolt something in again from a third party maybe you do want to add that to your stack maybe you don't or again you can do some low-level programming vertex gives us this event bus out of the box it recognizes this is something that we want to do this is something that we're going to need to do and allows us to communicate across those verticals on multiple threads across verticals on multiple instances of the JVM maybe distributed to cost mini machines and then also all the way down into the browser so I've got a single communication model that is available to me everywhere my code is running and then nodejs requires all the codes are on the event loop if you've got blocking work you're going to run into problems vertex gives us the background workers that allow that blocking work to be done off of the event loop now there's a lot of other goodies in there stuff that you know you can compose your applications with we have a growing module repository multiple modules you can pull in to your own apps and then communicate with those over the eventbus so we've got a you don't have to necessary sources we've got a web server module we have a persister that has been around for a while JDBC is fairly new we have the work queue that I've mentioned very simple authentication manager probably not good enough for most of you works well for demos but we need something better session manager has just come out we've got a socket IO implementation also very nice detailed feature set I didn't want to go spend my time walking through api's with you I know you guys can all go read so I didn't want to read api's back to you but there's a whole list of things out there several things that we didn't cover of course we've got full WebSocket support we've got the ability to do timers and do timed work with a scheduler of course we've mentioned buffers we also get a very good support for streaming and pumping of data between verticals we can do routing of requests of course they have a full-featured non blocking asynchronous file IO API these are all very well documented one of the great things about vertex is that for the most part it's very well documented and if you do have problems you know enough to go jump off into the source code and see how things are working and figure out what's going on this is how I figured out most of the shared memory stuff okay so I promised a case study what is the case study the case study is a Twitter clone called twit X it's using of course vertex bootstrap and then knockout Jas to do the event handling and binding in the browser the code for this I pushed up this morning to github so you can pull it down to play with it it's not quite ready for just out-of-the-box consumption there's some manual legwork that has to be done in MongoDB over the next few days I'm gonna get that documented and also try to build the features into the app to make it network go away but I just wanted to give you a heads up on that but all the code that we're gonna look at is in fact available yes the appeal to participation vertex is young vertex needs help there's one guy working full time on this the rest of it is people like us spending our spare time doing stuff so there is a google group it is fairly active I probably get anywhere between 5 and 15 messages a day a lot of its where's the framework going how are we going to implement this a lot of it's also how do I do this so it's kind of a merger of developers and users asking for help codes on github there's an IRC chat I haven't done that before but I know it exists so what do we need well we said you can program in any language that you want if your language isn't there we need you to implement a language handler for it so those opportunities are there particularly we're looking for folks who are interested in working on closure modules we need more persistence modules right now we can do we can use JDBC there was a Redis one that we had for a while and then it died and now we're trying to resurrect that but you know what if you want to do couch you want to do des Tomic some other store but I'm thinking about doing the de Tomic one myself but at any rate we need that security is a big need you want to do any kind of modern security we just don't have that yet and of course we need people to talk about it so we need examples we need blogs we need help with the documentation all of these opportunities are there you say can I help with this the answer is yes every time so need you guys to get involved and that's all I have one last thing that I ask of you I have this talk up on speaker rate I will be giving this talk several times I appreciate your feedback so if you take the time to go visit that URL and fill out an evaluation tell me what you like about the talk tell me what sucks about the talk so that I can make it better for the next group of folks who get to sit through it all the images were Creative Commons with the exception of a couple others that I had permission for so I need to show you that okay thank you guys for coming I appreciate it

Channel: InfoQ

Views: 24,029

Keywords: Node.js, Vert.x, java, javascript, ruby, grails, python, techtv, maraka, video

Id: 8ClYUo_A3h0

Length: 55min 41sec (3341 seconds)

Published: Wed Nov 21 2012