Server Queue Timeout Handling via Asynchronous Response Retrieval

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing synchronous client-server interactions face challenges in handling timeouts due to heavy server traffic or short client timeout periods, leading to application complexity, excess server workload, and business-level problems.

Innovation Solution

Implement a method that switches from synchronous to asynchronous response patterns by providing a response storage location for client requests at risk of timeout, allowing clients to retrieve responses proactively using a shared endpoint.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If synchronous client-server interactions are used, then response delivery is straightforward and reliable, but client requests may timeout due to heavy server traffic or queue delays

Engineering Contradiction:
Improveresponse delivery reliabilityVSAvoidclient request timeout
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system dynamically switches between synchronous and asynchronous response patterns based on server queue conditions. When timeout risk is detected, the system transitions from synchronous to asynchronous pattern, allowing clients to retrieve responses later without timeout errors. This dynamic adaptation resolves the contradiction by maintaining reliability while avoiding time loss.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The server performs preliminary assessment of queue conditions and timeout risks before processing requests. By identifying at-risk requests in advance and preparing asynchronous response mechanisms, the system prevents timeout occurrences rather than reacting after they happen, thus maintaining reliability without time loss.

Inventive Principle:
Principle #10Preliminary action

2Productivity

If the server queue grows large or processing delays occur, then server capacity is exceeded, but client requests timeout before reaching the front of the queue

Engineering Contradiction:
Improveserver processing capacityVSAvoidrequest completion reliability
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The system introduces an intermediary asynchronous response mechanism that bridges the gap between server processing delays and client expectations. Instead of direct synchronous communication failing under load, the intermediary allows requests to be queued and responses delivered asynchronously, maintaining completion reliability even when server capacity is exceeded.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system dynamically adjusts its response pattern based on server load conditions. When the queue grows large or processing delays occur, it transitions from synchronous to asynchronous pattern, ensuring that requests are not lost due to timeout while the server processes at its maximum capacity.

Inventive Principle:
Principle #15Dynamics

3Reliability

If applications implement retry logic for timeout recovery, then request completion may be achieved, but application complexity and server workload increase

Engineering Contradiction:
Improverequest completion reliabilityVSAvoidapplication complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The server provides self-service timeout handling by automatically managing asynchronous response delivery. Instead of requiring applications to implement complex retry logic, the server itself handles the timeout recovery by storing responses and delivering them asynchronously, thus maintaining reliability while reducing application complexity.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system introduces an intermediary asynchronous response mechanism that simplifies timeout handling. Rather than applications needing to implement retry logic, the intermediary automatically manages response delivery, reducing application complexity while maintaining request completion reliability.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Reliability

If retry logic is implemented for timeout recovery, then requests may be reprocessed, but excess server workload is generated

Engineering Contradiction:
Improverequest completion reliabilityVSAvoidserver workload efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The server provides self-service timeout handling by automatically managing asynchronous response delivery. This eliminates the need for retry logic that would generate excess server workload, as the server efficiently handles timeout recovery through its built-in asynchronous mechanism rather than reprocessing requests.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system discards the timeout error state and recovers by delivering the original response asynchronously. Instead of reprocessing requests through retries (which generates excess workload), the system recovers the original response and delivers it through the asynchronous channel, maintaining reliability while preserving server productivity.

Inventive Principle:
Principle #34Discarding and recovering

Data Source

PatentUS12621369B2Handling timeouts of client requests to a server
Publication Date: 2026.05.05 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US12621369B2 patent drawing
  • US12621369B2 patent drawing
  • US12621369B2 patent drawing

AI summary

A method and computer system for handling timeouts of client requests to a server. The method includes: accessing timeout metadata of a synchronous client request at a server queue; determining that the synchronous client request has a timeout risk; identifying a response storage location for a request processor to use to store a response to the synchronous client request when the response is provided after the timeout of the synchronous client request; responding to the synchronous client request indicating a user of a response storage location for asynchronous response retrieval; and providing the identifier of the response storage location as metadata in the synchronous client request when sending the synchronous client request to the request processor for processing.