InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Transparent Persistent Configuration Caching

IP.com Disclosure Number: IPCOM000249253D
Publication Date: 2017-Feb-14
Document File: 3 page(s) / 110K

Publishing Venue

The IP.com Prior Art Database


Disclosed is a methodology for applications that need external server configurations during startup. This methodology holds the external server configurations in local cache which is transparent to the application. That caching mechanism is configured to intercept outbound requests from the application to the configuration system. Local cache gets updated on each successful response from the remote server. Local cached configurations get into action when the remote server configuration is not reachable. This proposed methodology aims to increase the availability of the overall system. This methodology can be incorporated to any existing application without making any further changes to the application itself.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Transparent Persistent Configuration Caching

A software component may depend on external configuration that resides in external systems (configuration repositories), that are fetched upon restart, loaded lazily, queried periodically or fetched based on an external change notification. Whatever the method, such a system depends on at least a single successful fetch of required configuration information for correct operation.

During normal operation external configuration repositories may become unavailable due to crashes or peak load. Also the component itself may be recycled, due to planned maintenance, a crash, or an active / passive switch in an HA environment. In such cases component does not become available unless all other systems it depends for configuration become, or already are, available. This runtime dependency reduces high availability and increases RTO (Recovery Time Objective) of the whole system.

In many cases last known configuration for such a component is good enough for operation, and may be reused given it is readily available by some other means.

Method proposed utilizes augmenting the host / container that runs the client system with a caching transparent proxy, that uses same persistent storage (local disks) as the system for cache persistence. All outbound network communication is transparently filtered, and cached. Configuration is served via local cache if origin server cannot be reached, or times out.


If the document requested from configuration repository is retrieved successfully (206), transparent proxy stores / updates the document in local file system cache (210), and returns the document to User system.

If configuration repository cannot be reached or times out, then proxy server tries to retrieve the document, using URL as the cache key, from local file system cache (207).

If local cache contains the document, it is served back to User System (208). Otherwise an error code is returned (209) User System is a software component (101), running on a host or container (100). Configuration for this software resides in an external Configuration Repository (102). [Fig. 1]

User system, upon booting up, fetches this external configuration, or configuration may be fetched lazily as required, or both.

In one embodiment User system uses HTTP (Hypertext Transfer Protocol) protocol for fetching configuration. In this case, a transparent caching http proxy is configured on the client machine (103). [Fig. 2]

Proxy is configured to intercept outbound requests (well known methods already exist for such configuration, like iptables). A list of outbound URL...