Does Vert.x has real concurrency for single verticles?

Question

the question might look like a troll but it is actually about how vert.x manages concurrency since a verticle itself runs in a dedicated thread.

Let's look at this simple vert.x http server written in Java:

import org.vertx.java.core.Handler;
import org.vertx.java.core.http.HttpServerRequest;
import org.vertx.java.platform.Verticle;

public class Server extends Verticle {
    public void start() {
        vertx.createHttpServer().requestHandler(new Handler<HttpServerRequest>() {
           public void handle(HttpServerRequest req) {
                req.response().end("Hello");
           }
        }).listen(8080);
    }
}

As far as I understand the docs, this whole file represents a verticle. So the start method is called within the dedicated verticle thread, so far so good. But where is the requestHandler invoked ? If it is invoked on exactly this thread I can't see where it is better than node.js.

I'm pretty familiar with Netty, which is the network/concurrency library vert.x is based on. Every incoming connection is mapped to a dedicated thread which scales quite nicely. So.. does this mean that incoming connections represent verticles as well ? But how can then the verticle instance "Server" communicate with those clients ? In fact I would say that this concept is as limited as Node.js.

Please help me to understand the concepts right!

Regards, Chris

In netty there is no fixed mapping between threads and connections---that is in fact its key advantage over the classic java.io synchronous I/O. Threads are recruited from a thread pool only when there is actual work to do. — Marko Topolnik, Jul 22 '13 at 13:38
I think a key principle of a verticle is that every event is served by a single thread (or at least that each and every event for a specific verticle is sequentially executed). So, no, Vert.x does *not* have concurrency for a single verticle, and that's the point of it. — forty-two, Jul 22 '13 at 22:50

score 7 · Answer 1 · answered Jul 23 '13 at 09:01

I've talked to someone who is quite involved in vert.x and he told me that I'm basically right about the "concurrency" issue.

BUT: He showed me a section in the docs which I totally missed where "Scaling servers" is explained in detail.

The basic concept is, that when you write a verticle you just have single core performance. But it is possible to start the vert.x platform using the -instance parameter which defines how many instances of a given verticle are run. Vert.x does a bit of magic under the hood so that 10 instances of my server do not try to open 10 server sockets but actually a single on instead. This way vert.x is horizontally scalable even for single verticles.

This is really a great concept and especially a great framework!!

But are those 10 instances of your Verticle running on a single dedicated event loop or are they spread across multiple event loops running on a single Vert.x instance. 10 instance on a single event loop would mean no concurrency, but parallel processing for multiple requests as long as the code is asynchronous and 10 instance across event loops would mean possible concurrency issues with shared state. — Tomek Samcik, Mar 16 '22 at 11:26

score 1 · Answer 2 · answered Jul 25 '13 at 02:13

Every verticle is single threaded, upon startup the vertx subsystem assigns an event loop to that verticle. Every code in that verticle will be executed in that event loop. Next time you should ask questions in http://groups.google.com/forum/#!forum/vertx, the group is very lively your question will most likely be answered immediately.

score 1 · Answer 3 · answered Jun 04 '17 at 16:31

As you correctly answered to yourself, vertex indeed uses async non-blocking programming (like node.js) so you can't do blocking operations because you would otherwise stop the whole (application) world from turning.

You can scale servers as you correctly stated, by spawning more (n=CPU cores) verticle instances, each trying to listen on same TCP/HTTP port.

Where it shines compared to node.js is that the JVM itself is multi-threaded, which gives you more advantages (from the runtime point of view, not including type safety of Java etc etc):

Multithreaded (cross-verticle) communication, while still being constrained to thread-safe Actor-like model, does not require IPC (Inter Process Communication) to pass messages between verticles - everything happens inside the same process, same memory region. Which is faster than node.js spawning every forked task in a new system process and using IPC to communicate
Ability to do compute-heavy and/or blocking tasks within the same JVM process: http://vertx.io/docs/vertx-core/java/#blocking_code or http://vertx.io/docs/vertx-core/java/#worker_verticles
Speed of HotSpot JVM compared to V8 :)

Also note that V8 was never intended to be used on the server-side, nodejs just happened at some point, JavaScript is a very bad starting point for raw performance. The JVM always competed against C/C++ for performance and has a long history of server-side usage, this is why it is quite fast now: https://www.cubrid.org/blog/inside-vertx-comparison-with-nodejs — Christophe Roussy, Oct 02 '17 at 08:32

Does Vert.x has real concurrency for single verticles?

3 Answers3