Under certain circumstances (e.g. recovering from a large-scale outage) it may be helpful to ensure certain workflows are executed at a higher priority than other workflows, even within the same task list.
So far I can think of a couple of different ways to handle this, one or more of which may work together to achieve the desired effect:
Allow dynamically changing the worker and decider pool sizes
Support strict prioritization of certain workflow types over others (e.g. never execute tasks for a workflow with low priority if tasks for a workflow with high priority are pending)
Support dynamically-adjustable, capacity-percentage-based allocation of worker threads to different workflow types based on those same priorities (e.g. only use up to 20% of available worker threads for workflow type A)
Strict prioritization is achievable using SWF's TaskPriority field, which can be set on a per-activity-execution basis. Flux could provide an optional callback mechanism that the decider can use to look up what workflow- or activity-level priority to use when scheduling each attempt. This has the benefit of letting SWF do the actual prioritization work, so Flux doesn't have to poll for work and then decide whether to reject the received task.
It's also worth noting that these aren't mutually exclusive options; we likely should support all of them at some point, if possible.
Under certain circumstances (e.g. recovering from a large-scale outage) it may be helpful to ensure certain workflows are executed at a higher priority than other workflows, even within the same task list.
So far I can think of a couple of different ways to handle this, one or more of which may work together to achieve the desired effect:
Strict prioritization is achievable using SWF's TaskPriority field, which can be set on a per-activity-execution basis. Flux could provide an optional callback mechanism that the decider can use to look up what workflow- or activity-level priority to use when scheduling each attempt. This has the benefit of letting SWF do the actual prioritization work, so Flux doesn't have to poll for work and then decide whether to reject the received task.
It's also worth noting that these aren't mutually exclusive options; we likely should support all of them at some point, if possible.