Daemon Session Framework for Robust Background Event Processing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing background services lack robustness in event processing, leading to loss of messages and resources upon crashes or restarts, which can disrupt mission-critical processes and require additional health checks and maintenance efforts.

Innovation Solution

Implementing a daemon session framework that stores start parameters and unprocessed messages in robust memory storage, allowing automatic restarts and continued processing even after crashes, using shared memory to ensure data persistence and reliability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a daemon session is restarted due to crashes or updates, then service availability is improved, but unprocessed messages are lost and processing integrity deteriorates

Engineering Contradiction:
Improveservice availabilityVSAvoidmessage loss
Core Design Contradiction:
ReliabilityVSLoss of information

Solution Approach 1:

The system performs preliminary actions by storing start parameters and unprocessed messages in robust memory storage areas before a restart occurs. The framework captures messages in flight and preserves them in a message queue that survives restarts, ensuring that when the daemon session restarts, both the configuration parameters and pending messages are already available, preventing any loss of processing integrity.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The framework acts as an intermediary between the application session and the daemon session. It intercepts messages intended for the daemon session, stores them in a robust message queue, and manages the transfer of both start parameters and unprocessed messages during restart scenarios. This intermediary layer ensures that the daemon session can be restarted without losing messages or processing context.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Speed

If start parameters are stored in memory during daemon operation, then quick access is improved, but data loss upon restart worsens

Engineering Contradiction:
Improveparameter access speedVSAvoiddata persistence
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

The framework performs preliminary action by storing start parameters in a robust memory storage area that is configured to survive restarts. Before the daemon session starts or restarts, the framework ensures that the start parameters are captured and preserved in this persistent storage area, so when the daemon session needs to access them during or after restart, they are already available without risk of loss.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If health checks and manual monitoring are implemented, then service reliability is improved, but system complexity and maintenance effort increase

Engineering Contradiction:
Improveservice monitoringVSAvoidmaintenance complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The framework enables self-service by automatically managing the daemon session lifecycle, including automatic restart detection, message queue management, and start parameter preservation. The system monitors its own health and automatically recovers from crashes without requiring external health checks or manual intervention, thereby reducing system complexity and maintenance effort while maintaining high reliability.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS10652338B2Event processing in background services
Publication Date: 2020.05.12 SAP SE
  • US10652338B2 patent drawing
  • US10652338B2 patent drawing
  • US10652338B2 patent drawing

AI summary

The present disclosure involves systems, software, and computer implemented methods for event processing in background services. One example method includes receiving a request to create a daemon session, the request including at least one parameter. The session is created, including storing the at least one parameter in a memory storage that is configured to survive a restart of the session. A set of messages is received for the session. The messages are stored in a queue that is configured to survive a restart of the session. A determination is made that the session is to be restarted. A restart of the session is initiated, including providing the at least one parameter to the session during the restart of the daemon session and providing unprocessed messages to the session after the session has been restarted, to enable the session to process the unprocessed messages.