For a long time JVM developers have been sitting out watching web developers write agile and performant applications with frameworks such as node.js. Fortunately this is no longer the case. Vert.x is a powerful, bleeding edge event-driven application framework for the JVM. It features native support for non-blocking I/O and concurrency. It has a distributed event bus that that allows real-time communication between client and server. In addition to including out-of-the-box modules for easy development, vert.x has a module system that enables code reuse. To be even more cool, vert.x is polyglot, supporting components written in different languages such as Javascript, Ruby, and Python. In this speech I will give an overview of the vert.x framework and some of the caveats that you should be aware of.
Streamlining Python Development: A Guide to a Modern Project Setup
Development with Vert.x: an event-driven application framework for the JVM
1. Development with Vert.x:
an event-driven application
framework for the JVM
David Wu
@wuman
blog.wu-man.com
Taiwan Java User Group (2013/06/29)
1Monday, July 1, 13
4. What most people will tell you about Vert.x
• A general-purpose application framework
running on JVM
• Performant: asynchronous APIs, event-driven,
non-blocking, etc.
• Highly scalable but also easy to implement
concurrency
• Polyglot: intermix Java, JS, Ruby, Groovy,
Python, etc.
4Monday, July 1, 13
5. What I think about Vert.x
• All-in-one framework that allows you to focus
on your application rather than fiddling with
different technologies
• Business friendly Apache License 2.0
• Loose coupling modules that interoperate in a
system
5Monday, July 1, 13
7. Shift from Threading
to Asynchronous
the story of switching from Apache to Node.js
7Monday, July 1, 13
8. The inevitable comparison to Node.js
• A single event loop serving a high volume of
connections via an asynchronous
programming model
• Most of the real work are done in a pool of
background threads
8Monday, July 1, 13
10. But there are 3
problems with Node.js
10Monday, July 1, 13
11. Problems with Node.js
• Well, it’s not Java (and this is a Java User
Group)
• Does not easily scale both vertically and
horizontally
• Single event loop fails when you have CPU-
intensive tasks or 3rd-party blocking APIs
11Monday, July 1, 13
12. Vert.x to the rescue
• Use all available cores on a single machine
• Horizontally scale out to multiple boxes
• Allow blocking calls to NOT run on an event
loop
12Monday, July 1, 13
13. Introduction to Vert.x instance and Verticles
Verticle
Verticle
WorkerVerticle
WorkerVerticle
Vert.x instance
13Monday, July 1, 13
14. Verticles are extremely isolated
• Verticles are isolated with separate class
loaders
• A verticle never gets executed by more than
one thread concurrently
• No race conditions, no deadlocks. You write
your code as single threaded.
14Monday, July 1, 13
21. Point-to-Point Model
eb.send("test.address", "This is a message",
new Handler<Message<String>>() {
public void handle(Message<String> message) {
System.out.println("I received a reply " + message.body);
}
});
EventBus eb = vertx.eventBus();
Handler<Message> myHandler = new Handler<Message>() {
public void handle(Message message) {
System.out.println("I received a message " + message.body);
message.reply("This is a reply");
}
};
eb.registerHandler("test.address", myHandler);
21Monday, July 1, 13
22. Shared Maps and Sets
ConcurrentMap<String, Integer> map = vertx.sharedData().getMap("demo.mymap");
map.put("some-key", 123);
Set<String> set = vertx.sharedData().getSet("demo.myset");
set.add("some-value");
22Monday, July 1, 13
24. Writing Verticles
import org.vertx.java.core.Handler;
import org.vertx.java.core.net.NetSocket;
import org.vertx.java.core.streams.Pump;
import org.vertx.java.platform.Verticle;
public class Server extends Verticle {
public void start() {
vertx.createNetServer().connectHandler(new Handler<NetSocket>() {
public void handle(final NetSocket socket) {
Pump.createPump(socket, socket).start();
}
}).listen(1234);
}
}
vertx run Server.java
24Monday, July 1, 13
25. Deploying Verticles programmatically
// For example - deploy some other verticle
container.deployVerticle("foo.js", new AsyncResultHandler<String>() {
public void handle(AsyncResult<String> deployResult) {
if (deployResult.succeeded()) {
System.out.println(“Yay!”);
} else {
System.out.println(“Error: “ + deployResult.cause());
}
}
});
25Monday, July 1, 13
26. Modules
• Package verticles into re-usable modules
• Simply a zip file containing module definition,
code, and resources
• Very similar to the module system in Node.js
• Modules can be “zip” artifacts released in
Maven Central
• Vert.x web site maintains a listing of Vert.x
modules
26Monday, July 1, 13
27. Example Modules
• JDBC, Redis, MongoDB Persistors
• AMQP
• Mailer
• Persistent work queue
• Authentication Manager
• Session Manager
• Web framework
• Language implementations
27Monday, July 1, 13
35. Real life caveats
• Content assist in IDEs don’t work for busmod APIs
• You often find yourself tracing errors in the busmods,
which can be difficult because the stack trace stops
at message passing
• People writing in other languages often get frustrated
by not being able to use native extensions that they
are already used to.
• Hell of anonymous inner class callbacks and no good
Java flow control libraries
• Java7 only. Doesn’t work on Android.
35Monday, July 1, 13