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
Oldest
•
Newest
•
Most likes
•
Fewest likes
-
07 Nov, '20
Olena Sherbinin SystemHighlighted comment
"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. -
11 Jul, '20
Karthik MergedAbility to Cancel Queued/Running Execution or Executions (Bulk) of a Flow