Skip to main content

Organize Long Tasks

We define tasks with a time limit of more than 10 s as “long tasks”, where the results of the mission cannot be obtained immediately, and we need to wait for the end of the mandate before proceeding to the next node.

Rill Flow is designed to keep the process context stored and therefore does not lose the context of the process execution even if it is restarted or upgraded in the long task.

We divide our common long tasks into four categories, and Bill Flow can be interfaced with these types of long tasks in different ways.

In practice, it is not recommended that the Rill Flow arrangement be used for tasks that have been carried out for more than one month (of course, it can be organized).

Receive call - waiting for long tasks

Once a mission is launched, it will be necessary to synchronize and wait for the interface to return. Depending on the mode of deployment of the corresponding service, there can be two interfaces with:

Call the cloud service:dispatcher to create an asynchronous thread pool

When the corresponding execution service is deployed on the public website, it can be done by adding asynchronous execution thread pools to the dispatcher, avoiding sending threads to be packed for long periods of time by long assignments. Please refer to the ChatGPT plugin in the code.

When the Rill Flow service itself restarts, the corresponding request will also be lost. Elegant shutdown related logic will need to be added to the dispatcher

Adds an executor Agent with:

When the corresponding executor is self-serving, it is recommended that an additional call be made to the service by Sidecar, with a request from Agent to maintain the service as well as the actual service and that the agency return Rill Flow at the end of the request to notify the task execution.

executor agent

By adding Agent, it is effective to avoid failure of long connection requests due to network or other problems.

For call-poll long tasks

Get token, after launching the task, and then get progress through the Task Query Interface.

  • Add two nodes to the process
  • Passing token between tasks through the parameter mapper

For call-back long tasks

Assign callback when launching the task and call the specified interface when the task is complete.

Return the Rill Flow to complete the interface directly in the task, or the business implements the callback logic by converting the original task request to encapsulate and then calling to Rill Flow.

For stream long tasks

Once a mission is launched, it will be possible to write data continuously to a certain inflows.

Rill Flow currently does not support original streaming task configuration, and needs to encapsulate flow logic to Executor itself.