Here below is a workflow implementation for a shared pool of resources able to accommodate long and short jobs with different max number of concurrent resources and different priorities.
Detect media files in a folder. Multiple files can be returned.
Start a workflow launcher for each detected file.
The MediaInfo action returns the duration of the media file.
The Filter step branches out long versus short job based on the returned duration.
Assign dedicated queues and resource managers to long and short jobs. The managed resources are virtual, not tied to a real action. They just allow to specify different max number of concurrent resources for long and short jobs.
Assign different priorities to long and short jobs. Here it’s done via a merge point checking which of long or short resource id is not empty. It may also be done via a filter.
Assign a queue and resource manager to a pool of real resources (e.g. FlipFactory transcodes) shared between long and short jobs.
Release the real resources when the action is completed.
Release the virtual resources.
As an example, you can set 2 max concurrent long jobs, 6 max concurrent short jobs and a total of 8 concurrent jobs.
An alternative design would be to have dedicated real resource managers for long and short jobs. As they don’t share the resources, it may be that one resource manager would have some free slots while the other is fully busy and has pending requests for resource. So the resource utilization may not be optimum.
Yet another design would be to forget about dedicated queues and resource managers for long and short jobs, and just assign different priorities to them. Thus, there is no way to control the max number of long jobs versus short jobs, but it’s guaranteed that short jobs will be treated before long jobs when they are detected in the same timeframe.