Application Server Failed Event Queue Management
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cloud-based software applications with stateless and scalable architectures face challenges in error handling, particularly when dealing with failed requests, as the flow may no longer be available for retrieval, making it difficult to retry requests or determine appropriate remedial actions.
Innovation Solution
A system and method for processing failed events on an application server, where failed events and their related processing flows are stored in a failed event queue, allowing for analysis and corrective actions to be taken, including replaying flow instances to address failures.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If the flow engine retrieves flow documents on a request-by-request basis to achieve stateless and scalable architecture, then the application becomes scalable, but error handling becomes more challenging and flows may no longer be available for retrieval when retries are needed
Solution Approach 1:
The system performs preliminary action by storing flow instances in memory before they are needed for retry operations. The flow instance store maintains copies of flow documents proactively, so when an event fails and retry is needed, the flow is already available without requiring retrieval from external storage. This resolves the contradiction by ensuring flow availability (reliability) while maintaining the request-by-request processing model (scalability).
Solution Approach 2:
The flow instance store acts as an intermediary component between the event processing system and external flow storage. It provides a buffer layer that decouples the scalability benefits of on-demand retrieval from the reliability requirements of retry operations. The intermediary holds flow instances temporarily, allowing the system to scale while ensuring flows remain available for error handling scenarios.
2Reliability
If flow instances are stored in memory to enable retry operations, then error handling capability is improved, but memory resource consumption increases
Solution Approach 1:
The system applies local quality by storing flow instances selectively in memory based on specific criteria rather than universally. Flow instances are loaded into the flow instance store when certain conditions are met (e.g., when they are about to be processed or when retry scenarios are anticipated). This selective storage approach provides error handling capability where needed while controlling overall memory consumption across the system.
Solution Approach 2:
The system implements partial action by maintaining only a subset of flow instances in memory at any given time, rather than storing all possible flows. The flow instance store holds flow documents that are likely to be needed for retry operations, accepting that not all flows will be cached. This partial caching strategy provides sufficient error handling capability while avoiding excessive memory resource consumption.
3Ease of operation
If the system deletes failed events from the event queue to maintain queue cleanliness, then event queue management is simplified, but information about failure reasons is lost
Solution Approach 1:
The system applies copying by creating and storing copies of failed event data in the dead letter queue before deleting them from the main event queue. When an event fails processing, its data including failure reasons is copied to the dead letter queue for later analysis. This allows the main event queue to be kept clean and simple for active event management, while preserving failure information separately for diagnostic purposes.
Solution Approach 2:
The system extracts failure reason information from failed events and stores it separately in the dead letter queue. By taking out the failure data from the main event processing flow and placing it in a dedicated failure storage area, the system simplifies event queue management for successful events while preserving failure information in a separate location where it can be analyzed without interfering with normal event processing.
Data Source
AI summary
The present invention is a method and system for an application server to process failed events of a predetermined software flow. An event generator generates an event to include event data and a related processing flow of a software application which processes the event. Each processing flow has a unique flow ID. An event queue is populated with events, and the processing flow is processed by an event processor. When an event fails, the application server deletes the event and its related processing flow from the event queue, then inserts and links the failed event, its related software application and processing flow, and one or more reasons for failure into a failed event queue.