Setting worker pool size: VertxOptions vs DeploymentOptions

[Alex Z.]

Hello!

In my application, I have a single Vert.X instance that deploys N instances of my ServiceVerticle. In one of the route handlers I am performing a blocking call with the help of executeBlocking. When configuring the worker pool size, I see that both VertxOptions and verticle DeploymentOptions allow to setWorkerPoolSize - what's the difference?

1. If I am deploying 5 instances of my verticle and I am allocating 100 threads for the worker pool size in DeploymentOptions, does it mean that I have a pool of 500 threads available or the five instances share the 100 thread pool?

2. Same question regarding VertxOptions: If I am deploying 5 instances of my verticle and I am allocating 100 threads for the worker pool size in VertxOptions, does it mean that I have a pool of 500 threads available or the five instances share the 100 thread pool?

In a different scenario where application does not spawn any threads (no executeBlocking, no blocking handlers, no CompletableFuture.runAsync, etc.), what happens to the default worker threads (I believe the default is 20)?

1. Does Vert.X creates a thread pool with the default number of threads? Do they just idle there or Vert.X may or may not use them internally?

Thank you

[Julien Viet]

On Sep 23, 2017, at 6:29 AM, Alex Z. <azagn...@gmail.com> wrote:

Hello!

In my application, I have a single Vert.X instance that deploys N instances of my ServiceVerticle. In one of the route handlers I am performing a blocking call with the help of executeBlocking. When configuring the worker pool size, I see that both VertxOptions and verticle DeploymentOptions allow to setWorkerPoolSize - what's the difference?

the VertxOptions worker pool size applies to the default Vert.x worker pool.

the DeploymentOptions worker pool size allows you to have a separate worker pool per deployment : http://vertx.io/docs/vertx-core/java/#_verticle_worker_pool

probably the documentation could be improved a bit and say that in a per deployment worker, the settings can be different (i.e size or blocking time limit).

1. If I am deploying 5 instances of my verticle and I am allocating 100 threads for the worker pool size in DeploymentOptions, does it mean that I have a pool of 500 threads available or the five instances share the 100 thread pool?

it will be 100 threads shared between the instances.

2. Same question regarding VertxOptions: If I am deploying 5 instances of my verticle and I am allocating 100 threads for the worker pool size in VertxOptions, does it mean that I have a pool of 500 threads available or the five instances share the 100 thread pool?

it is global, there will be 100 threads shared between all the workers of the Vert.x instance as well as the executeBlocking calls.

In a different scenario where application does not spawn any threads (no executeBlocking, no blocking handlers, no CompletableFuture.runAsync, etc.), what happens to the default worker threads (I believe the default is 20)?

1. Does Vert.X creates a thread pool with the default number of threads? Do they just idle there or Vert.X may or may not use them internally?

yes it is 20, the thread pool is created but as far as I remember, the thread pool creates the thread on demand (to be checked).

Vert.x has an internal blocking pool (size 20 too) that is used for various blocking operations such as Filesystem that is used for some blocking operations (flush).

Thank you

--
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 https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/bb3d85e9-2737-415a-8981-bc08aef796e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Z.]

Thank you!

[Bill Davis]

Wouldn't having a thread pool size of 100 be wasting 95 threads unless the workers are multi-threaded?

[Alex Z.]

It should not, if verticle instances make the "executeBlocking" call, then the pool threads will be used. This is at least my understanding 

[Julien Viet]

yes it will if you consider only the verticles.

that being said, the vertx worker pool is shared between all the verticles deployed in the vertx instance

so you can consider it’s a general purpose worker pool.

this worker pool is also used internally by Vert.x to perform some blocking operations, for instance sending a message with Hazelcast can use this worker pool as well.

> On Sep 27, 2017, at 7:42 PM, Bill Davis <bda...@gmail.com> wrote:
>
> Wouldn't having a thread pool size of 100 be wasting 95 threads unless the workers are multi-threaded?
>

> --
> 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 https://groups.google.com/group/vertx.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/1a4648be-4213-4760-8483-0fcb801fde4e%40googlegroups.com.