Shared Memory Request Queues for Worker Node Failover

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing application servers face inefficiencies and session loss due to the overhead of establishing connections between the connection manager and J2EE dispatcher, as well as the risk of session loss when a virtual machine crashes, particularly in standards-based software suites lacking shared memory structures.

Innovation Solution

Implementing a shared memory system with request/response shared memory regions and notification queues across multiple worker nodes to facilitate efficient request handling and failover, allowing seamless transfer of sessions from a failed worker node to another, thereby enhancing reliability and reducing session loss.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If connection manager establishes separate connections to each worker node for request notification, then request delivery is reliable, but system overhead and complexity increase

Engineering Contradiction:
Improverequest delivery reliabilityVSAvoidconnection management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces a notification queue as an intermediary component between the connection manager and worker nodes. Instead of establishing direct connections from the connection manager to each worker node, requests are placed in notification queues that worker nodes monitor and process. This intermediary mechanism reduces connection management complexity while maintaining reliable request delivery.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Speed

If worker node processes requests from local queue, then processing speed is fast, but session loss occurs when worker node fails

Engineering Contradiction:
Improverequest processing speedVSAvoidsession persistence
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

The patent implements preliminary action by maintaining request notifications in persistent notification queues before worker nodes process them. When a worker node fails, the requests remain in the notification queue rather than being lost, allowing another worker node to pick them up. This preliminary preservation of request state in shared memory structures prevents session loss while maintaining fast processing when nodes are operational.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If multiple worker nodes share common memory structure, then session transfer during failover is efficient, but memory access contention increases

Engineering Contradiction:
Improvefailover capabilityVSAvoidmemory access efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent segments the shared memory structure into distinct notification queues that can be independently accessed. Instead of having all worker nodes compete for the same memory region, each queue is organized to facilitate efficient access patterns. This segmentation allows multiple worker nodes to share memory structures while reducing access contention and maintaining both failover capability and productivity.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS8140678B2Failover protection from a failed worker node in a shared memory system
Publication Date: 2012.03.20 SAP SE
  • US8140678B2 patent drawing
  • US8140678B2 patent drawing
  • US8140678B2 patent drawing

AI summary

A method is described that involves entering a notification of a request into a queue that supplies request notifications to a first worker node amongst a plurality of worker nodes. The first worker node is targeted to process the request. In response to the first worker node failing before the notification could be serviced from the first queue, the notification is moved from the first queue to a second queue that supplies request notifications to a second worker node amongst the plurality of worker nodes. After servicing the notification from the second queue, the request is transferred to the second worker node. A response to the request is then generated with the second worker node.