Worker pool thread selection

[Alessandro Chacon]

Hello,

I have realized that when having a Working Verticle and an alternative pool [.setWorker(true).setWorkerPoolName] the consumed event bus messages are NOT processed in a thread chosen in a round robin fashion when the messages are sent very fast (tens in less than a second). All of the messages end up being consumed by the same thread.

I'm not sure if this is also a behavior of using the standard pool for a Worker Verticle.

I thought it was said before that the thread selection on a Worker Verticle is always done in Round Robin. Is this not the case when consuming many events? Is the Round Robinness partitioned by a time range? (e.g. every 50ms choose the next thread)

Appreciate the answers.

[Alessandro Chacon]

I'm using Vertx 3.9.5 by the way.

[Thomas SEGISMONT]

Hi,

You need to deploy as many instances of the worker verticle as you have threads in your custom pool.

Otherwise the single instance of the worker verticle handles events one after the other (using the same thread or not makes no difference then).

--
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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/8067d211-93bc-4d54-858b-1f219b71f33an%40googlegroups.com.

[Alessandro Chacon]

Hello,

Thank you for your answer. I'm not sure what do you mean. The point of a Worker Verticle is that I can use different threads that might block to serve the requests (in this case the events in the event bus), so they should not be handled one after the other. Or am I wrong?

[Thomas SEGISMONT]

Le mer. 24 mars 2021 à 15:40, Alessandro Chacon <alessand...@cryptobroker.ch> a écrit :

Hello,

Thank you for your answer. I'm not sure what do you mean. The point of a Worker Verticle is that I can use different threads that might block to serve the requests (in this case the events in the event bus), so they should not be handled one after the other. Or am I wrong?

A worker verticle instance handles events one after the other on a worker thread.

If you want concurrency you need to create several instances (setInstances on DeploymentOptions)

 

On Wednesday, March 24, 2021 at 3:36:27 PM UTC+1 tsegi...@gmail.com wrote:

Hi,

You need to deploy as many instances of the worker verticle as you have threads in your custom pool.

Otherwise the single instance of the worker verticle handles events one after the other (using the same thread or not makes no difference then).

Le mer. 24 mars 2021 à 15:10, Alessandro Chacon <alessand...@cryptobroker.ch> a écrit :

I'm using Vertx 3.9.5 by the way.

On Wednesday, March 24, 2021 at 3:10:06 PM UTC+1 Alessandro Chacon wrote:

Hello,

I have realized that when having a Working Verticle and an alternative pool [.setWorker(true).setWorkerPoolName] the consumed event bus messages are NOT processed in a thread chosen in a round robin fashion when the messages are sent very fast (tens in less than a second). All of the messages end up being consumed by the same thread.

I'm not sure if this is also a behavior of using the standard pool for a Worker Verticle.

I thought it was said before that the thread selection on a Worker Verticle is always done in Round Robin. Is this not the case when consuming many events? Is the Round Robinness partitioned by a time range? (e.g. every 50ms choose the next thread)

Appreciate the answers.

--
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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/8067d211-93bc-4d54-858b-1f219b71f33an%40googlegroups.com.

--
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.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/a5908732-f445-46e2-bfd7-55334578e835n%40googlegroups.com.

[Alessandro Chacon]

Yes, but that's on the same worker thread. However the Worker Verticle thread selection on incoming events on the event bus is round robin right? so on every incoming message I would expect to use a different thread. However what's happening to me is that events are processed in some sort of clusters, so every 50ms or so (I haven't measured it) a different thread is selected to consume the event.

[Alessandro Chacon]

Otherwise, if I'm understanding this wrongly, why do I get different threads every time if I consume let's say 1 event every 10 seconds?

[Thomas SEGISMONT]

When deploying a worker verticle, you get the guarantee that, on a single instance, events will be handled one after the other. It could be with the same thread, or different threads. But it doesn't make any difference performance-wise, given events are handled one at a time.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/6bb2eb4d-e1d6-414b-b2f1-b02e81b03ca3n%40googlegroups.com.

[Alessandro Chacon]

OK I see. I see the point where indeed there is no difference performance-wise, that's a great point and I will take it into account, thanks! 

I want to make sure I know, however, what's the thread selection method. It's not round robin then?

[Thomas SEGISMONT]

The round robin selection is for consumers of an eventbus address. Perhaps you were thinking about this, I don't know

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/9ba5948b-2a6a-4589-93b6-9e75842f607fn%40googlegroups.com.

[Alessandro Chacon]

Yes, this is exactly what I'm talking about. I have a single consumer on an eventbus address. This consumer is called using the exact same thread if many events are happening in a short time (tens in a second). However if the events happen not so frequently (1 every second) the thread used seems to be selected in round robin (worker-1, worker-2, worker3,.....).

Do you have any idea why? It seems to me like it's some sort of time range clustered based round robin selection.

[Thomas SEGISMONT]

Le mer. 24 mars 2021 à 16:17, Alessandro Chacon <alessand...@cryptobroker.ch> a écrit :

Yes, this is exactly what I'm talking about. I have a single consumer on an eventbus address. This consumer is called using the exact same thread if many events are happening in a short time (tens in a second). However if the events happen not so frequently (1 every second) the thread used seems to be selected in round robin (worker-1, worker-2, worker3,.....).

Do you have any idea why? It seems to me like it's some sort of time range clustered based round robin selection.

I haven't checked the implementation but I assume that after a worker has handled an event, it checks if there are any other events pending.

 

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/1f55bda2-fc1e-460f-bea6-5eb0f3fa6601n%40googlegroups.com.