Vert.x Kue | A brief introduction to how it works
In this blog post, I’ll give a brief introduction to illustrate how Vert.x Kue works.
In the workflow, first we deploy the KueVerticle in clustered mode and register the JobService on the event bus. The JobService consists of various logic of Job. After that, we could then deploy KueHttpVerticle to provide REST API. Most of the apis calls Future-based methods in Kue. Finally we could deploy our job processing verticle. The verticle usually consists of three parts:
- create
Kueinstance
When we create Kue instance, the inner JobService proxy and redis client will be created. Also, the static Vertx field in Job class will also be initilized.
- create and save
Job
Here we could set job properties and subscribe events from the job address(via event bus).
- process the
Job
When we call the process or processBlocking method, Vert.x Kue will create and then deploy some KueWorkers, which is a kind of verticle(or worker verticle, if calling processBlocking).
In KueWorker, we first get Job from Redis backend (zpop operation):
1 | private void prepareAndStart() { |
If the KueWorker successfully gets the job, it will do process procedure. First we set started_at flag on the job and then save it to the backend. Then we emit the job start event on the event bus(both job address and worker address). Next, we will process the job using the given handler. Simultaneously, we consume done and done_fail events on the job-specific address. If done event received, the job should be completed and we emit complete event. If done_fail event received, the job should be failed so we first do a failed attempt. If attempt failed, then send error event on worker address. Else send failed or failed_attempt event depending on the attempt status.
There are three kinds of address:
1 | /** |
Diagram
