
Vert.x – JVM Polyglot Alternative to Node.js - lnmx
http://www.infoq.com/news/2012/05/vertx
======
andrewvc
I'm really excited about this. While node-js is a great project, it still
doesn't have the awesome instrumentation and tooling around it the JVM does.
Additionally, real threading is damn nice, and the JVM definitely has that.

Combining this with languages like ruby, clojure, and scala seems like a
definite win.

~~~
Zak
I'm not sure.

Async-by-default doesn't seem like a great model for programming the server-
side part of most things that are done over HTTP. Three use cases jump out at
me:

1\. Javascript doesn't have threads, but you want to write a usable HTTP
server in it.

2\. Threads are scary.

3\. You want to make certain actions asynchronous over HTTP (i.e. client says
"start", then server maybe says "done" later).

Now consider Clojure:

1\. Clojure has threads (on the JVM, at least) and one typically uses an
existing Java web server when a web server is called for. Unlike Javascript
when node.js came out, Clojure isn't lacking options for running or writing a
web server.

2\. Clojure makes a lot of threaded operations pretty non-scary. Its native
data structures are all immutable and it has constructs for concurrent state.
These are not any harder to work with than the async/callback model. I find it
more natural, but I'm used to Clojure so that could be bias.

3\. Async-when-desired is already easy in Clojure. Futures provide a very easy
way to do stuff in a thread pool without blocking. Agents provide the same
thing for state changes. It really is as easy as (future do-blocking-thing)
and (send-off an-agent do-blocking-thing some-args).

I can imagine why I might want this sort of thing in certain languages in
addition to Javascript, but why would I want it in Clojure?

------
Uchikoma
Finagle works fine. Thank you. Love it. But it does not take off. Why?

What all the JVM Node.js clones are missing and what Node.js sets apart are
async libraries. There is no async (MySQL) JDBC driver for starters. If your
IO drivers are not async, your async container is not very useful in real
life.

~~~
kyleburton
This. The biggest difference is in the two cultures: blocking is anathema to
the Node.js community - they will literally reject libraries or code that
blocks because it destroys the entire model; the JVM community does not value
non-blocking code - most of the core (JDBC, Networking in general, File system
operations) is all written in a blocking style - the JVM community accepts
this with the implicit assumption that threads will help assuage those issues.

Python, Ruby and Perl all have the same cultural tolerance for blocking code.
The Node.js community has a complete lack of tolerance for blocking code.

I work with the JVM every day (Clojure) and wish it was different wrt the
common use of non-blocking code, but it's going to be a long road to get there
on the JVM.

Kyle

~~~
pron
Java _Executor_ s combined with Guava's _ListenableFuture_ s easily turn any
blocking operation to an asynchronous one.

Netty's entire model is asynchronous, and Java 7 now has _AsynchronousChannel_
s for IO which, I assume, Netty will make use of.

All in all, the JVM has a much more solid and performant foundation than
anything Node can provide. The whole difference will come down to a
programming style preference. I am not entirely sure why Vert.x adopted the
Node style rather than the proven servlet container, as I'm sure both styles
provide comparable performance. I guess each may shine under different
loads/usage patterns (my guess is that Vert.x/Node can squeeze more
performance from a single thread, but servlets are more scalable).

~~~
Uchikoma
There is no async MySDQL JDBC driver. If you encapsulate it in an async layer,
you need to keep a thread for the connection.

~~~
tensor
Maybe I am missing something, but how can you possibly have an async SQL
driver without threads like this? This sounds like a case of your Node.js
database driver hiding the exact same behaviour described here within C code.

~~~
purplefox
If the wire protocol for the driver is published, then you can write a 100%
async driver for it. I.e. no threads blocking, ever. In fact, I already did
this for redis and vert.x (I will dig out the code for this some time).

If you are dealing with something where you don't know what the wire protocol
is and you just have a blocking client library to play with (e.g. JDBC - JDBC
is, _by definition_ blocking - see the JDBC API), then you can't do much but
to wrap the blocking api in an async facade and limit the number of threads
that block at any one time. This is exactly what we do in vert.x. We accept
the fact that many libraries in the Java world are blocking (e.g. JDBC) so we
allow you to use them by running them on as a worker. This is one area where
we differ from node.js. Node.js makes you run _everything_ on an event loop.
This is just silly for some things, e.g. long running computations (remember
the Fibonacci number affair?), or calling blocking apis. With vert.x you run
"event-loopy" things on the event loop but you can run "non event-loopy"
things on a worker. It's a hybrid.

~~~
Uchikoma
A limited number of threads will not scale as real async wake-on-data
connections will scale. If demand is higher than your thread pool, for the use
case that you're web response builds on async backend requests, your site will
be down.

------
jhspaybar
Maybe I'm one of the weird ones, but I absolutely love types and would
probably write everything in JS if it had typing similar to Java or C++. As it
is, I'm using Java on Jetty instead for my current web application but would
love to see a really solid event Node.js style typed framework. With that
said, at this point I'm not sure I'd give up my Servlets, frameworks(like
CometD) for doing WebSockets, and the other niceties that a true servlet
container gives me. I can't wait to see where this goes though!

~~~
stcredzero
There's only two kinds of weirdos in this world. Those who love types, and
those who don't.

------
Animus7
Impressive. It's basically a kinda-sorta-rewrite of Node.js APIs on the JVM.

Looking through the docs, the main difference I see is that this is opting for
a comparatively heavy-core approach which contrasts with Node's ruthless
minimalism + third-party modules.

For example:

-file system access is convoluted with HTTP handling: req.response.sendFile()

-pieces of web framework functionality by default, but no full solution (RouteMatcher)

-integrated WebSockets with a novel but unconventional accept/reject API

-heavyweight SockJS integration

It will be interesting how all of his plays out. And I'm definitely interested
in hearing evidence for claims such as

> a run-time with _real_ concurrency and unrivalled performance

~~~
stephen
> -file system access is convoluted with HTTP handling:
> req.response.sendFile()

I haven't looked in to it, but just guessing this is probably so that it can
do 0-copy sending of files (e.g. doesn't have to buffer/stream the contents
through the JVM).

~~~
purplefox
That's right. If you use the sendFile() method and you're on an OS that
supports it, then the kernel will do the copying directly from file to socket
for you.

You can also serve files in the more conventional "node.js-style" way (i.e.
pump the buffers manually from file to socket) if you like. It's just slower
than getting the kernel to do the work for you.

~~~
dap
But you have to dedicate a thread to sendFile() (by nature).

~~~
dap
(Response to jbooth, but for some reason I can't reply to that directly.)

The whole point of sendfile is to make one system call to send all the data in
one stream to another, which in general may block. If you're polling and
sending only small chunks at a time (whatever you can write without blocking),
is it really that much of an advantage over read/write on the same poll? (If
you're not doing that, then you have to block, and you have to dedicate a
thread to it.)

~~~
jbooth
If the socket you're writing to has been set to nonblocking, then sendfile
exhibits the behavior I described, sending EAGAIN sometimes (check man
sendfile). This means typically you want to put a selector in front of it and
poll the selector, then send to any sockets that are writable, loop back and
poll again.

It's still an advantage over read/write because you're getting the 0-copy
behavior.

------
abeatnik
The install pre-requisites recommends that Windows users install a linux VM -
but I found the beta 11 version works directly.

~~~
purplefox
Yes, vert.x should work directly on Windows. I shall update the wiki
accordingly :)

------
sausagefeet
Frustrating to see a library like this be called "Next generation" when the
code structure is a step backwards as far as I can tell. We have had green
threads, and more than that green threads that can multiplex over multiple
cores for a long time. Let's move on, people.

------
dap
From the article:

> InfoQ: What about running a real-time app on the JVM vs. on Node.js, with
> respect to debugging, monitoring and operations?

> Answer: I'd say monitoring and operations are really the concern of the
> environment in which you deploy vert.x than vert.x itself. e.g. if you
> deployed vert.x in a cloud, the cloud provider would probably provide
> monitoring for you.

This makes it sound like a toy. How can I deploy something to production when
I have no way of seeing what it's doing? How is a cloud provider supposed to
provide debugging/introspection for JavaScript running on the JVM (by means of
a brand new facility)?

------
treenyc
also look at <http://ringojs.org>

~~~
qznc
also look at <http://vibed.org/>

~~~
loftsy
also look at Apache AWF <http://incubator.apache.org/awf/>

------
sehugg
Looks like a user-friendly interface to Netty and Hazelcast with some special
sauce sprinkled in. I love Netty, and Hazelcast is, er, interesting and
hopefully getting more reliable. Should be fun.

~~~
ww520
Netty and Hazelcast are amazing pieces of software. I've used them with good
success. Hazelcast is another unique enabler that makes the impossible or
difficult to do trivial.

------
dotborg
This is not anything new, this funcionality is part of Apache Cocoon since
almost 10 years and is called Flowscript:
<http://cocoon.apache.org/2.1/userdocs/flow/api.html>

You can use and create Java objects from your JavaScript.

------
emblemparade
There are other alternatives for polyglot JVM goodness, for example this based
on Restlet:

<http://threecrickets.com/prudence/>

Plus a whole framework based around MongoDB:

<http://threecrickets.com/savory/>

------
pan69
Trying to install this on Ubuntu. Is it me or is the "binary" download link
[1] not really a binary download link?

[1] <https://github.com/purplefox/vert.x/downloads>

~~~
purplefox
Works fine here:

<https://gist.github.com/2594983>

Are you sure you're not looking at the github tags, rather than the downloads?

~~~
pan69
OK. I think I know what I did wrong. On the Github (download link on the
website) I click "Download .tar.gz" assuming I was getting the latest version.
I might got the latest version but it seems to be the latest of source. I
should have chosen one of the packages.

------
mattgreenrocks
I was hoping it provided an alternative ideology to node.js in the form of
fibers.

~~~
purplefox
Fibers (or equivalent constructs) aren't supported by all the languages that
Vert.x supports (e.g. Java) so we can't really support something like that
until we can do it in all the langs.

I know Fibers/Green threads are all the rage right now, and it is certainly
something to keep an eye on, but I am not entirely convinced that roll your
own threading is going to be any more performant than what the kernel can do.

If we can find a way of implementing fibers efficiently, that supports
millions of fibers on a single JVM instance, I would be interested.

------
almost

        req.response.sendFile('webroot/' + file);
    

!!!!

I'll have file='../../secret.txt' thanks

~~~
purplefox
Yes, of course in a real web server you'd make sure you do the checks ;) The
documentation actually mentions this point explicitly :)

~~~
almost
I'm pretty sure I don't want to use a web server by people who think a 5 line
demo that gives unrestricted access to the hosts file system is the best way
to show off it's capabilities. Sorry, but that's just stupid.

~~~
purplefox
[http://vertx.io/core_manual_js.html#serving-files-
directly-d...](http://vertx.io/core_manual_js.html#serving-files-directly-
disk)

~~~
almost
I'm unsure what you're trying to say there. Yes, I am aware that it's possible
to serve files without exposing your whole file system. Did you think that was
something that might be in doubt?

------
anuraj
This is most welcome. Hope they continue to support this effort. We need more
light weight approaches in established languages like Java.

------
salimmadjd
I went through their tutorial and it seems very enticing. hopefully it'll get
some real traction and broader support.

------
wiradikusuma
i wonder how is it compared to servlet container (e.g. tomcay and servlet
spec?

~~~
hanswesterbeek
it ignores those, for good reason

~~~
ExpiredLink
which is?

~~~
tsewlliw
Every concurrent request gets its own thread, whereas this seems to be one
thread per core.

Also, the servlet API is crazy, partly because of all its baggage. There seems
to be a lot of exploration around what the right API is right now, but its
pretty clear the world wants something new.

~~~
pron
> Every concurrent request gets its own thread, whereas this seems to be one
> thread per core.

No. Servlet containers use a thread pool (that grows and shrinks dynamically).

~~~
pivo
There's really no conflict between the statement, "every request gets it's own
thread" and the use of thread pools.

The point is that a given request in a servlet container is handled in it's
own thread. That thread will probably come from a pool and be reused to handle
another request of course, but that's sort of immaterial.

------
lucian1900
So it's more like Twisted (a library) than Node (a runtime + a library).

~~~
tantalor
Node is more like a library than a runtime. Its runtime is V8. The node libs
could be ported to another JavaScript engine such as jsc, narwhal, or ringo.

> Node.js consists of Google's V8 JavaScript engine plus several built-in
> libraries.

<http://en.wikipedia.org/wiki/Nodejs>

~~~
lucian1900
Node ships with both runtime and async library, unlike Twisted, which doesn't
ship Python.

