Deploy Verticles Dynamically

[an7...@gmail.com]

Hi, 

Is it common practice to deploy/un-deploy verticles dynamically? or this approach is not recommended?

For example, if there are multiple HTTP request that needs to be executed in parallel, I could deploy a vertical for each, and with the assumption that they will run in different "event loop" threads, their execution will be in parallel.

Once request execution is completed, these Vericles are no longer required, so, they will be un-deploy. In the next batch of HTTP request, new Verticles will be deployed.

This is ONLY an example for a functionality that is needed temporarily and thus there is no need to keep the Verticle throughout the life cycle of the application.

So, the question is whether the "deploy"/"un-deploy" are heavy, and it is not recommended to do it often through the life cycle of the application?Should we deploy all Verticles in application startup, and assign them tasks when required (through the message bus)? Or, there is no problem with dynamic deploy/un-deploy, and these operations are not "heavy" in terms of performance?

I'll appreciate your advice on this.

Thanks, Aliza 

[ad...@cs.miami.edu]

Verticles are pretty light, and you can have a number of them, and you can deploy them dynamically.

However, your use case does not seem to be a natural fit for deploying separate vertices to handle individual http requests. If you have a standard verticle listening as an http server, it will have an event loop which be able to handle request in parallel (of sorts), as a series of events on the loop ( if you want more info on how it does this read the docs and ask here if you need clarifications).  If you want to handle requests in parallel (in the traditional sense), you do not need to launch new verticles, but use the "executeBlocking" method to run blocking code on worker thread.  Or, you can send the blocking call to a worker verticle (note you do not need to dynamically create this worker, just create it at the start).

A typical http server will run as one (or a few) instances of an http server which occasionally branches off to an executeBlocking/worker verticle to handle edge cases of blocking code.

-Adam

[an7...@gmail.com]

Hi, 

Thanks for your response.

The use-case I wrote was only an example (maybe not a good one :-) ) for a need of "temporary" Vertical, and wanted to know whether the deploy/undeploy operations are considered heavy. And as I understand from your response, they are not :-).

In addition, you mentioned the "ececuteBlocking" and Worker verticles, and I am familiar with these two from the documentations. 

Regarding this two, is it recommended to heavily use this in application? If we'll use it heavily,  won't it make the whole idea of Vert.x as a light application meaningless?  The application will become heavy - multiple threads, many context switch, application has to deal with synchronizations etc. What would you recommend?

 

Thanks, Aliza

[dominik....@trivago.com]

Well, the use of blocking code should be avoided as much as possible in a vertx (or, actually, any) application.

But that is not always possible, e.g. when using a proprietary API. In those cases, there is usually no way around it and then it is helpful to have such facilities to seamlessly incorporate that code into the vertx application.