In Mendix Version 9 and above, a Task queue is introduced to allow the developer to asynchronously run the microflow or any java actions by controlling a various number of tasks that are executed simultaneously by queuing them to the task queue list. This helps the developer to build high-performing applications without thinking about synchronization and task management. The developer can configure the task queue.
Task Queue in Mendix Version 9
What Is The Task Queue?
Task Queue is a horizontal scalable queuing solution to assist developers to create applications more reliable and perform better. Developer can perform long-running tasks in the background to prevent the user from having to wait, divide the load across multiple runtime instances, and optimally allocate resources by using multiple queues.
Task queue is used where there’s a high magnitude of transactions, tasks increase time or accuracy is essential. Developers can queue from a scheduled event and can also work around the scheduled event and ensure collection of tasks are always executed.
How to start?
Task queue is very simple. Once the developer adds new task into the queue in Mendix Studio Pro version 9 and after adding Task Queue in task queue list, developer can indicate on a Call microflow activity that the microflow should be executed within the background. After enqueueing the task, it’ll be picked up by one among the runtime instances for processing.
Replacing The Process Queue Module
The way of executing tasks within the background supersedes the sooner Process Queue Marketplace module.
The major differences between Process Queue and Task Queue are
- Task Queue supports a native part of Mendix and multimode cluster setup and can thus be used in horizontally scaled environment and also requires no extensive setup of additional entities and associations lowering the complexity of the domain model of the applications.
- Task Queue does not require the additional entities to be created, since microflows or java actions are often marked easily to execute within the background and also allows for horizontal scaling, making it the go-to solution for multi-instance environments.
- Task Queue does not support any automatic retry of failed tasks and it also supports automatically retry tasks that are on the roadmap for later this year.
Creating Task Queues
Background execution is done in so-called Task Queues.
- Right-click on a module or folder.
- Select Add other.
- Click Task Queue.
- Enter the value for Threads for each cluster node (maximum 40).
Task Queues have several threads. Each of these threads will be processed one task at a time. That is, a queue will devour as many concurrent tasks as possible because of its threads. Whenever a task is finished, subsequent ones are getting to be picked up. In general, one or two threads should be enough, unless there’s an outsized number of tasks or tasks take an extended time and wish to execute in parallel. Having many threads will put additional load on the database and cannot be done if not needed. The total number of worker threads is restricted to 40 (per cluster node). there’s no hard limit on cluster nodes.
Task Status
The Status attribute of System.QueuedTask and System. ProcessedQueueTask reflects the state that a background task is in.
The values are:
- Idle: The task was created and is waiting to be executed.
- Running: The task is being executed.
- Completed: The task was executed successfully.
A System.ProcessedQueueTask is added to reflect this. - Failed: The task is not any longer executing because an exception occurred. A System.ProcessedQueueTask containing the exception is added to reflect the failure. The task won’t be retried.
- Aborted: The task is not any longer executing, because the cluster node that was executing it went down. A System.ProcessedQueueTask is added to reflect this. The task is going to be retried on another cluster node.
- Incompatible: The task was never executed, because the model changed in such how that it can’t be executed anymore. this might be because the microflow was removed/renamed, the arguments were changed, or the Task Queue was removed.
Shutdown
During the shutdown, the TaskQueueExecutors will stop accepting new tasks. Running tasks are allowed a grace period to end. After the grace period ends, an interrupt is sent to all task threads that are still running and again allow a grace period for them to finish. After the second grace period, the runtime just continues shutting down, eventually aborting the execution of the tasks. The aborted tasks are going to be reset, in order that they’re re-executed later or on another cluster node. In development mode, the primary grace period is shortened to 1 second.
Limitations
- Microflows or Java actions that are executed within the background employing a sudo/system context with all permissions. it’s impossible to use a user context with limited permissions.
- Background microflows or Java actions will start execution as soon because the transaction during which they’re created is completed. This ensures that any data that are needed by the background microflow or Java action is committed also. it’s impossible to start out a background microflow or Java action immediately, halfway during a transaction.
- The total amount of parallelism per node is restricted to 40. this suggests that at the most 40 queues with parallelism 1 are often defined, or one queue with parallelism 40, or somewhere in between, as long because the total doesn’t exceed 40.