In Vertx official docs I read the following paragraph
If a result can be provided immediately, it will be returned immediately, otherwise you will usually provide a handler to receive events some time later.
Because none of the Vert.x APIs block threads that means you can use Vert.x to handle a lot of concurrency using just a small number of threads.
And in article about Reactor:
Vert.x works differently here. Instead of a single event loop, each Vertx instance maintains several event loops. By default we choose the number based on the number of available cores on the machine, but this can be overridden.
As I understand, please correct my if I write something wrong, Vertx works in the following way:
When we provide a handler to blocking code, vertx put one thread(not event loop) to this code from thread pool that equals to the number of cores for example I have 4 cores, and event loop check the state of this thread after each iteration and if it ready execute handler that relate to this blocking code, when all 4 cores are busy vertx put task to the queue to be executed later,
What about worker verticle, we have another thread pool that by default is equal to 20, when we use following method: vertx.executeBlocking() we use thread from this pool.
Is my understanding correct?
(PS) According to the asnwer below there is no difference between blocking code with handler and blocking code with handler but using execute blocking
//jdbc
connection.execute("insert into test values (1, 'Hello'), (2, 'World')", insert -> {
// query some data with arguments
connection.queryWithParams("select * from test where id = ?", new JsonArray().add(2), rs -> {
if (rs.failed()) {
System.err.println("Cannot retrieve the data from the database");
rs.cause().printStackTrace();
return;
}
}
//worker thread
vertx.executeBlocking(e->{},handler->{});
Is my understanding right, both codes use worker thread under the hood?
