Vert.x vs thread pool

[Vi Dao Kieu]

Hi everyone,

I'm confusing with Vert.x.

In example http://vertx.io/docs/vertx-web/java/#_basic_vert_x_web_concepts , if as Reactor pattern then

server.requestHandler(router::accept).listen(8080); Is this line similar to a Synchronous Event Demultiplexer (an event loop)

and Router will be an Dispatcher for each HTTP Request Event, while the Handler involved will be created a thread to execute?

As I know one of advantage of reactor pattern is non blocking I/O but in this case I don't see the different between Vert.x vs Thread pool approach. I know I'm having misunderstanding here, hope to get your help.

[Nat]

Have you read this?
http://www.cubrid.org/blog/dev-platform/understanding-vertx-architecture-part-2/
http://tutorials.jenkov.com/vert.x/overview.html#vertx-thread-model

[Vi Dao Kieu]

I've read them but I still don't understand.  It seems keeping in my mind that Vertx should know where I/O blocking and handle this such this answer .

Could you explain to me in the case HTTP server handling request, what advantages of vertx-web?

[Nat]

Vertx does not really know where IO blocking. You are the one who knows it best so you need to do some of that. If you have anything that would be blocked, you should schedule it in worker thread (with vertx.executeBlocking). For vertx-web, you can think of them as just a library running on top of vertx-core. It provides route mapping and redirect them to an appropriate route handler. It pretty much has nothing to do with vertx threading model.

[Tim Fox]

On 13/08/15 03:09, Vi Dao Kieu wrote:

I've read them but I still don't understand.  It seems keeping in my mind that Vertx should know where I/O blocking and handle this such this answer .

I wish people wouldn't post Vert.x questions on SO. We don't answer them there.

Could you explain to me in the case HTTP server handling request, what advantages of vertx-web?

On Thursday, August 13, 2015 at 4:18:47 AM UTC+7, Nat wrote:

Have you read this?
http://www.cubrid.org/blog/dev-platform/understanding-vertx-architecture-part-2/
http://tutorials.jenkov.com/vert.x/overview.html#vertx-thread-model

On Wednesday, August 12, 2015 at 10:08:22 AM UTC-7, Vi Dao Kieu wrote:

Hi everyone,

I'm confusing with Vert.x.

In example http://vertx.io/docs/vertx-web/java/#_basic_vert_x_web_concepts , if as Reactor pattern then

server.requestHandler(router::accept).listen(8080); Is this line similar to a Synchronous Event Demultiplexer (an event loop)

and Router will be an Dispatcher for each HTTP Request Event, while the Handler involved will be created a thread to execute?

As I know one of advantage of reactor pattern is non blocking I/O but in this case I don't see the different between Vert.x vs Thread pool approach. I know I'm having misunderstanding here, hope to get your help.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/381562c5-359e-46ff-aeae-1571b5e53054%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Fox]

I don't understand what part you don't understand ;)

If you phrase your question a bit more clearly, perhaps we can answer it :)

On 13/08/15 03:09, Vi Dao Kieu wrote:

[Vi Dao Kieu]

Sorry for my representation. I'm being transferred a project using Vertx-web and I want to know why they chose vertx instead of Spring Rest API.

In the project, I see only one Verticle (one class) in which RouterMatcher delegating the specific Handlers for each Rest APIs and as I know each Verticle will be called in single event loop thread and when Verticle called, it will call a thread in background pool for a handler to execute? And when the number of request is larger than number of threads in background pool then is it similar to the case that the server will create each thread for each request?

[Jez P]

The server will NOT create a thread for each request. The handlers in a verticle all run on the same thread.

[Jez P]

(that should say in a verticle instance: if you have two instances of the same verticle, the handlers for each all run on a single thread but the sets of handlers (one set per verticle instance) could each be on a separate thread, ie all the handlers for verticle instance 1 will be on thread 1, all those for instance 2 will be on thread 2, and thread 2 may or may not be the same thread as thread 1.

[Vi Dao Kieu]

Thank Jez P very much, as you said then if I run two instances of the same verticle is similar to a REST API app deployed to two HTTP Servers, so what advantages of vertx in this case? And when a handler executing then it will block the verticle?

[Tim Fox]

Please don't post the same message multiple times.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/35ca113b-ab54-4f2f-ad33-c49729b1c06e%40googlegroups.com.

[Jez P]

That verticle instance will only execute one piece of code at a time, you're right. However, avoiding spawning loads of threads ultimately reduces overhead. The key point is that you don't do blocking i/o on an eventloop thread, so the parcel of code on your eventloop thread is dealt with quickly. If you have a large operation, or blocking i/o to execute, then you will need to put it onto a worker pool thread (worker verticle or executeBlocking) to keep the eventloop threads responsive. 

I suggest you start by reading the documentation, the threading model is very well covered in the documentation and the blogs. 

One other point: you can build a REST API app in vert.x so I don't understand the distinction you're drawing in your question.

[Vi Dao Kieu]

Thank you again for all your help

[bytor99999]

One other huge difference I find is that Vert.x would be able to handle a LOT more requests, non-blocking the Main Thread, than any Web Container could with their "connections" pooling.

Basically, I could run one instance of Vert.x which might require 10 or more Web Containers to match the performance. The overhead of Vert.x is extremely smaller than a web container like Jetty or Tomcat. And the whole Java EE JSP/Servlet/REST footprints.

Mark

[Hakucha]

Hope, This video https://vimeo.com/96425312 might help you grasp the concept of non blocking & eventloop.