Implement priority queue and throttling for user-defined APIs (listeners)
Scenario 1: upstream system slammed the system with thousands of API calls in a short span of time, eventually freezing and requiring a reboot to stop all jobs
Scenario 2: one API could take a higher priority than another or one workflow or another – in a situation where 1000 jobs properly queue in one job – but another has one high priority job – a way to skip the line
Solution:
1. Add the ability to set the numeric priority for the API endpoint (listener). The lower the number the higher the priority of the endpoint. Calls to the endpoints with a higher priority will be processed first.
2. Add the ability to set the maximum number of the API calls that can be processed during a configurable amount of time. Other calls will be waiting in a persisted queue until the current batch of calls has been processed. On the restart, the environment will keep processing not yet processed requests that are sitting in a queue.
Comments: 3
-
11 Jul, '20
Karthik MergedAbility to Cancel Queued/Running Execution or Executions (Bulk) of a Flow
-
07 Nov, '20
Olena Sherbinin Admin"Ability to Cancel Queued/Running Execution or Executions (Bulk) of a Flow" (suggested by Karthik on 2020-07-11), including upvotes (2) and comments (0), was merged into this suggestion.
-
19 Feb, '21
Olena Sherbinin Admin