Understanding caching

Within HTTP 1.1, WebSphere® Voice Server provides support for a shared cache.

More precisely, WebSphere Voice Server supports a per-node-shared, HTTP public cache. This means all external references to public resources are cached and available to all sessions operating on that WebSphere Voice Server node. Any resource without a cache-control directive will be treated as shareable (public). Any resource with a cache-control directive of private will be treated as if its directive was no-cache. Any resource with a cache-control directive of 'no-store' will be treated as if its directive was no-cache.

Specifying cache request directives

The duality of HTTP allows clients to specify cache control directives. These are called cache request directives and are defined in MRCP and HTTP to be min-fresh, max-age, and max-stale. WebSphere Voice Server supports these directives in accordance with HTTP 1.1. Briefly defined, max-age permits a client the ability to restrict the age of a cached resource to be no greater than the provided value. In other words, the client is willing to accept a resource from the cache whose age in the cache is no greater than this value. On the other hand, max-stale permits a client the ability to restrict the age of an expired cached resource to be no greater than the provided value. In other words, the client is willing to accept stale content (expired) so long as it isn't stale for more than the provided value. HTTP also defines min-fresh. This header permits the client the ability to restrict the request to a resource whose freshness lifetime is greater than the value provided. In other words, the client can request a resource which will not expire for the minimum freshness value provided. In all cases, if the resource cannot be satisfied by the cache, the HTTP/application server is checked for a fresher copy. If one is available, it is fetched, placed in the cache and provided to the client. Otherwise the cached copy is used.

Defining cache directives in the resource

Some resource types can self describe their caching properties. These override any caching properties supplied by the web/application server and client. WebSphere Voice Server supports the following HTTP caching headers when supplied by the resource itself:

Date
Last-Modified
Expires
Note: See the appropriate resource type specification for details on how to supply HTTP caching headers.

For example to expire an SRGS-XML or Pronunciation Lexicon Specification (PLS) resource immediately, set the following tag in the document:

<meta http-equiv="Expires" content="0">

Note: This does not prevent the resource from being cached. It makes the resource stale for later use by the max-stale cache directive.

Enforcing cache correctness

WebSphere Voice Server supports the cache correctness rules defined by HTTP 1.1. In addition, WebSphere Voice Server also supports the HTTP "conditional GET" mechanism to reduce network traffic associated with revalidation when a resource is the freshest available. More specifically, if a cached resource fails to satisfy a client request, WebSphere Voice Server issues a GET with the 'if-modified-since' field set. If the response is 304 (Not Modified), WebSphere Voice Server does not re-request the resource rather, it uses the cached content according to HTTP 1.1.

Refreshing content from the origin server

It is helpful to use only the freshest copy of a resource. This can help, for example, in problem determination or in early application development.

Two mechanisms exist for re-validating at the origin server:

Use HTTP caching controls to "revalidate" the content. This is almost always accomplished by setting the max-age cache control directive to '0'. The web/application server is checked to see if a fresher copy exists and if so, WebSphere Voice Server fetches and uses this resource instead of the cached content.
Disable caching. Although not recommended for production use, resource caching will not occur when caching is disabled.
Note: Forcing resources to be re-fetched avoids caching and for this reason is not recommended for most deployment scenarios.

There are two ways to disable caching:

Alter the WebSphere Voice Server com.ibm.voice.server.rr.caching configuration property by setting it to false. See the Configuration parameters topic for more information on this property.
Configure the Web Server to set the HTTP cache-control header to no-cache for all resources, or just specific resource/types, that it serves up.

Caching resources in general

WebSphere Voice Server manages an origin server cache, normally referred to as the rrcache or the L1 cache. It provides support for HTTP public cache described previously, for all resource types entering WebSphere Voice Server thru the HTTP protocol. In addition, the L1 cache is responsible for maintaining the HTTP cache correctness rules for the system. The cache is self managing in that it not only provides boundaries for both its memory cache size and file cache size but also actively manages those boundaries. LRU (least recently used) and HTTP algorithms are used to decide what to prune when space is needed for new resources entering WebSphere Voice Server. See the Configuration parameters topic for available boundary parameters and their descriptions. Resources whose HTTP cache-control header is set to private, no-cache or no-store are not cached in either the memory or file system cache. The L1 cache size should be configured to a value that will contain all public resource used by the system including grammars.

WebSphere Voice Server hosted resources

All resources hosted by WebSphere Voice Server for use in speech applications (recorded audio via save-waveform, and save-best-waveform do not set any caching directives. For recorded audio, the default IHS server settings are used (no expires, default media-type).