Direct Asynchronous Workflow Launching With Shared-Queue Retries
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional job scheduling protocols in cloud computing systems experience noticeable latency and permit collisions between job launchers, leading to inefficiencies in processing workflow requests, especially for tenant-facing workflows.
Innovation Solution
Implementing an asynchronous job scheduling system that combines an optimistic path and a pessimistic path to manage workflow requests, where the optimistic path attempts to transmit requests quickly but without guarantees, and the pessimistic path continuously retries unsuccessful requests until successful transmission is achieved, using shared queues and multiple launchers to manage collisions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of time
If conventional job scheduling protocols are used, then system simplicity is maintained, but latency increases and collisions occur between job launchers
Solution Approach 1:
The job scheduling system is segmented into two independent paths: an optimistic path that attempts quick job transmission and a pessimistic path that handles retries. This segmentation allows each path to be optimized independently, reducing overall latency while maintaining manageable complexity through modular design.
Solution Approach 2:
The optimistic path performs preliminary action by attempting to transmit jobs immediately without waiting for confirmation of success. This preliminary attempt reduces latency by avoiding unnecessary waiting, while the pessimistic path provides a safety net for failed transmissions.
2Productivity
If multiple job launchers are used to improve processing capacity, then productivity increases, but collisions between launchers occur
Solution Approach 1:
A shared queue acts as an intermediary between multiple job launchers and the job processing system. The queue manages job distribution and prevents collisions by ensuring that only one launcher processes a given job at a time, thereby maintaining reliability while allowing multiple launchers to operate in parallel for improved productivity.
Solution Approach 2:
The system implements feedback mechanisms where the shared queue tracks job transmission status and provides information back to launchers. This feedback allows launchers to adjust their behavior, avoiding collisions by waiting for confirmation that a job has been successfully transmitted or is available for processing.
3Loss of time
If quick transmission attempts are made without guarantees, then latency is reduced, but transmission reliability decreases
Solution Approach 1:
The system dynamically switches between two transmission strategies based on conditions: the optimistic path provides fast, guarantee-free transmission for immediate processing, while the pessimistic path provides reliable retry mechanisms for failed transmissions. This dynamic approach allows the system to optimize for speed when possible and for reliability when necessary.
Solution Approach 2:
The pessimistic path serves as a beforehand cushion by pre-establishing retry mechanisms for the optimistic path. If the optimistic transmission fails, the cushioning effect of the pessimistic path ensures that jobs are not lost but are instead retried, thereby maintaining reliability without significantly impacting the overall transmission time.
Data Source
AI summary
Techniques are disclosed herein for a direct launch for asynchronous actions. An example method can include receiving, by a device, a first workflow request, wherein the device comprises a first launcher in operable communication with a second launcher via a shared queue, and wherein a first duplicate of the first workflow request is stored in the shared queue is to be retrieved by the second launcher upon an elapsing of a threshold time interval. The device can transmit the workflow request to an application for executing the first workflow request, wherein the transmission is prior to the threshold time elapsing. The device can determine whether the application initiated a workflow to process the workflow request. The device can update the first duplicate of the first workflow request stored at the shared queue based at least in part on the determination and prior to the threshold time interval elapsing.