Software Patch Testing via Concurrent Execution Contexts

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Software defects in service-oriented computing systems pose challenges for system administrators, as existing methods for testing software patches can introduce latent defects and require complex synchronization, especially in long-running servers with encrypted traffic, limiting the ability to test patches without affecting system availability.

Innovation Solution

The method involves injecting software patches into a program, running multiple instances of the patched program, and determining the patch's correctness by comparing outcomes, using a dynamic patch execution environment and supervision components to assess execution without disrupting the system.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If software patches are tested on non-production machines with mirrored traffic, then system availability is maintained, but cross-system synchronization overhead and complexity increase

Engineering Contradiction:
Improvesystem availabilityVSAvoidcross-system synchronization complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent creates virtual copies of the production system's execution environment within the same machine, allowing patch testing on copied execution contexts rather than requiring separate physical machines. This eliminates the need for cross-system synchronization while maintaining system availability.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The patent nests multiple execution contexts within a single production machine, creating hierarchical layers of execution environments. This allows running patched and unpatched versions concurrently without requiring external mirroring infrastructure, reducing synchronization overhead.

Inventive Principle:
Principle #7Nested doll (Nesting)

2Measurement precision

If software patches are tested on production systems, then realistic testing conditions are achieved, but system downtime is required

Engineering Contradiction:
Improvetesting accuracyVSAvoidsystem downtime
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The patent segments the production system into multiple isolated execution contexts, each capable of running independently with different patch versions. This allows testing patched versions alongside unpatched versions without requiring complete system shutdown, maintaining service continuity while achieving realistic testing conditions.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements dynamic execution context creation and destruction, allowing the system to flexibly spawn test instances during runtime and terminate them when testing is complete. This dynamic approach eliminates the need for static system downtime while enabling realistic patch testing.

Inventive Principle:
Principle #15Dynamics

3Reliability

If multiple execution contexts are created for patch testing, then comprehensive testing is enabled, but memory consumption increases

Engineering Contradiction:
Improvetesting comprehensivenessVSAvoidmemory consumption
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The patent merges multiple execution contexts into a single address space with isolated memory regions. By combining the testing infrastructure into one consolidated environment rather than separate processes, memory overhead is reduced while still enabling comprehensive multi-version testing through controlled memory isolation.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The patent implements local memory isolation where each execution context has its own protected memory region with specific access permissions. This allows comprehensive testing with multiple contexts while minimizing overall memory consumption by ensuring each context only allocates memory for its specific testing needs rather than duplicating entire system states.

Inventive Principle:
Principle #3Local quality

Data Source

PatentUS9606905B2Systems, methods, and media for testing software patches
Publication Date: 2017.03.28 THE TRUSTEES OF COLUMBIA UNIV IN THE CITY OF NEW YORK
  • US9606905B2 patent drawing
  • US9606905B2 patent drawing
  • US9606905B2 patent drawing

AI summary

Systems, methods, and media for testing software patches are provided. The methods include: injecting a software patch into a program; determining a portion of the program modified by the software patch; concurrently executing a first instance of the portion of the program prior to modification by the software patch and a second instance of the portion of the program that has been modified by the software patch; obtaining a first outcome of the first instance and a second outcome of the second instance; comparing the first outcome and the second outcome with a policy associated with the program; and determining whether the software patch has executed correctly based at least in part on the comparison.