Process Queue

Content Type: Module


This module allows you to execute microflows in parallel through the use of queues. You can control which microflows run in which queue and how many microflows run in parallel and even see the execution status of each action.

IMPORTANT: This module is deprecated and will not be upgraded to Mx 9. It is replaced by the Task Queue (, a native Studio pro component.



This module enables you to control the amount of these microflows that are executed at once by assigning them to queues. Each of these queues can be configured to handle a subset of these microflows and you can also set a limit to the number of microflows each queue can execute at once. This allows you to control the maximum load put on your application during peak usage by these microflows while still ensuring all microflows will be executed eventually. The queues use a FIFO approach (first-in, first-out) and will automatically restart themselves (and any microflows still left to execute) after a server restart.


This module enables you to control the load on your application by configuring different Queues. The amount of parallel processes and the number of queues can be controlled from the runtime and you’ll be able to see the progress real-time in your application. Typical usage scenario

  • You want to schedule a job but don’t want to execute the job at a specific time.
  • To control a process which crashes a server if to many users execute the action at the same time.
  • Create unlimited different queues.
  • Configure multiple different microflows to run in a single queue.
  • Configure multiple different microflows to run each in a different queue.
  • Control the nr of parallel threads per queue.


  • Mx Reflection Model module


After importing the module, you should connect the “QueueOverview” form to your application. This is the starting place for defining the different queues and processes. Add the microflow "ASu_InitialiseQueue" as a startup event to instantiate the queue. Before configuring the queue you need to synchronize the Mx Model Reflection module, make sure you sync the "ProcessQueue" as well.

Each microflow you’ll configure here should have one input parameter of the type: “ProcessQueue.QueuedAction”.

Off course you’ll want to retrieve the object for which you’ve created an queuedAction, the best way to do this is create an association from your object to the QueuedAction entity. This can either be a reference(set) with the default owner or the owner both, but try to prevent to add an association from QueuedAction to your entity. You should minimize the changes to this module.

In the microflow you’ve configured in the queue there should be an QueuedAction input parameter, using this parameter you can retrieve your object. In the folder: “Example / Test” you will found an example how to queue an action.


The constant: "FinishedQueuedActionsCleanupInDays" can be used to automatically clean up finished queued actions (through the scheduled event SE_CleanupFinishedQueuedActions): Negative value = disabled.0 = clear all finished actions1 or more = clear all finished actions that completed [1 or more] days ago.

Please note that (when dealing a large amount of actions in a short period of time): -> Create QueuedAction (no commit) -> add to list -> append to queue -> commit list of queued actions is inferior to: -> Create QueuedAction (commit) -> append to queue.

However both constructions should work now (tested batch sizes up to 10000 objects in size).

Automatic retry behavior:

The module will keep retrying exponentially for up to 11 retries. Initial retry will have a delay of 1 second (2^0), the second retry will take (2^1) seconds and the nth retry (2^n-1) seconds for a maximum of 2^10 = 1024 seconds for a combined total of 2047 seconds (=34 minutes) which is excessive but finite on purpose. In tests even adding 10000 actions at once (batch commit) will only take 5 retries (and only the first action is affected). This is basically the time it takes the microflow doing the batch commit (of queued actions) to complete.


Version: 8.0.0
Framework Version: 8.12.0
Release Notes: - Fix bug where actions without parameters where not accepted - Fix bug where multiple followup actions would crash
Version: 7.0.0
Framework Version: 7.23.22
Release Notes: - Upgraded the project to 7.23.22 - Fix bug where multiple followup actions would crash Note: the 7.x.x version will be used for 7.23 releases
Version: 4.2.0
Framework Version: 8.12.0
Release Notes: Updated the Process queue module to Mendix Studio Pro 8.12.0
Version: 4.1.2
Framework Version: 7.23.0
Release Notes: Mx8 compatible version.
Version: 4.1.1
Framework Version: 7.1.0
Release Notes: Version 4.1.1 - Fixed thread leak when calling - Improved memory management of the module due to differing behavior of IContext in Mx7 vs Mx6 - Fixed if check in FindCreateProcess microflow (already reported as an issue and in another pull request)
Version: 4.1.0
Framework Version: 7.1.0
Release Notes: - Fixed an issue with “Queued” actions remaining in the “Open” actions tab. - Fixed an issue with the process number of the QueuedAction not updating correctly. - Fixed an issue with the process number of the QueuedAction resetting to “0” after the action was successfully processed. - Removed Queue monitor information from QueueOverview page. o Queue monitor information did not refresh regularly quickly causing the information to become outdated. Unfortunately implementing refresh behavior did not appear to be easily possible. o Queue monitor information draws data from the underlying Java threads. The numbers did not always line-up with the information available in the QueueOverview page. This was confusing. o The fixes in the QueuedOverview page make the monitor even less relevant as the same information can now be drawn quite easily from the overview page itself. - Completely replaced retry mechanism that ensures FIFO ordering of the queues by implementing a pre-processing mechanism. o This should result in much less error-prone handling of records that are not yet available for processing due to a slight delay between committing in a microflow (i.e. in one thread) and being able to retrieve the record from the database in another thread. o It should process large amounts of queued actions (added at once) quicker and more reliably as records that cannot be found in the database will no longer delay the entire pre-processing of queued actions. - Removed while loop in ObjectQueueExecutor Java action that might have caused a queue to “hang”. An error will now be printed to the log instead. - Added scheduled event SE_ReinitializeQueues o When you run into a situation where one or more queues appear to hang for long periods of time, reinitializing the queue(s) can be a workaround to get them to start executing actions again. By default this scheduled event runs once an hour. - Removed full retry mechanism and replaced by preprocessing of actions before appending them to the queue. - Made a few changes to the _QueueAppenderThread functionality (Java) so restarting the thread is now possible. - The preprocessing functionality should resolve the issue of "stuck" queued actions, which should resolve ticket 59141. The above changes also resolve the Mx7.7+ context issue. So this should resolve the following tickets as well: 59621, 59394 and 61702
Version: 4.0.0
Framework Version: 7.1.0
Release Notes: Cleaned up the model and UI Enabled the Java actions to be used as a microflow activity Upgrade to Mx 7.1.0 Added the feature to configure the max nr of retry attempts through a constant (to avoid a 34min wait in case of a lock or failure) Fix for ticket 56473