Can you run concurrent instances of a verticle on a single vert.x ? Are those instances thread-safe?

Question

I know this question has already been asked, but I don't think it ever got a precise answer.

Can Vert.x run multiple instances of the same Verticle on a single Vert.x meaning that a single Verticle can run on multiple event loops ? If it is the case, is each of the event loops running the same handler instance or a separate one, in another words are multiple instances of the same Verticle thread-safe and not sharing any state or can there be concurrency issues ?

According to Vert.x documentation -

Even though a Vertx instance maintains multiple event loops, any particular handler will never be executed concurrently, and in most cases (with the exception of worker verticles) will always be called using the exact same event loop.

It's hard to tell what they mean exactly.

I'm trying to figure out how Actor model and Vert.x compare as far as concurrency and mapping to threads. So far it seems like Vert.x works like Actors where Verticle is a bundle of Actors assigned to a single thread and potentially the only difference is that in Vert.x one bit of code can run concurrently somewhere else (on the same Vert.x) although likely as a separate instance with its own state, while with Actors its strictly prohibited, unless you copy an Actor as a separate class and then it's the same.

---

Update: It seems like there is a full isolation of state between the instances running on separate event loops as each runs its own instance loaded via a separate classloader in a way that even static variables are not shared.

Here's an interesting thread about it.

And here's what ChatGPT has to say -

Answer 1

Yes, vertx can run multiple instances of the same verticle.

When a vertx instance is created it will create some number of event loop threads. By default it is 2 times the number of cpus on the machine.

All verticles deployed will be multiplexed onto those threads. You can have 100 verticles on 4 event loop threads.

But once a verticle has been assigned a thread it will always be executed from that event loop thread.

If you have a non atomic/thread safe variable global somewhere and you have verticles on more than one event loop - it is not safe to access that variable concurrently from multiple verticles. But inside a verticle everything is thread safe unless you launch your own different threads.

However, that is not the way it should be approached anyways. The app should me modeled as a verticle and then multiple copies should be deployed to utilize all the cores on your machine.

Everything inside the verticle can be thought of as thread safe since it is single threaded.

And if multiple verticles need to access global data - then use shared data, eventbus, locking, or any other concurrent friendly data structure like the concurrent hash map.

The foundational concept that needs to be understood is that I want my code to act and be safe as single threaded but I want to be able to use all the cores on my machine. How do you do that? You do that by deploying multiple instances of your verticle. Each instance is single threaded but since multiple instances are there they will utilize all the cpu cores.

It is similar to node.js - node js is single threaded so to utilize all cores on the machine devs deploy multiple copies of the processs. Jvm has true threading so instead of multiple jvms/processes we deploy multiple copies on different threads.

As far as actor model goes - a verticle can be thought of as an actor. You don't have to model ot that way since vertx is unopionanted. And messages are passed via the eventbus among them. Verticles are flat and have no hierarchy or supervision unlike akka or erlang's actor model which may or may not be needed for your use case.