When a message comes to the Cache Mediator, it uses message hashes to determine whether an equivalent message has been seen before. If the message has been seen before, the Cache mediator executes the
onCacheHit sequence (if specified), fetches the cached response, and prepares the ESB for sending the response. The
onCacheHit sequence can send back the response message using a Send Mediator. If the
onCacheHit sequence is not specified, the cached response is sent back to the requester.
The Cache Mediator evaluates the hash value of an incoming message as described in the optional hash generator implementation (a class implementing the
org.wso2.caching.digest.DigestGenerator class interface). The default hash generator is
org.wso2.caching.digest.DOMHashGenerator. If the generated hash value is found in the cache, the Cache Mediator will execute the
onCacheHit sequence, which can be specified in-line or referenced.
The Cache mediator does not cache the response status code of the HTTP response in the cache table. Instead, it returns the "200 OK" status code on a cache hit, which is the default request success status response. If you want to return a different status code when the request gets a cache hit, you can update the response status code in the
Cache Mediator Attributes:
- id - The Cache Mediator must be specified with an
idand two instances with the same
idthat correlates the response message into the cache for the request message hash.
- timeout - Optional attribute, which specifies the valid duration for cached elements. The scope defines if the mediator instances share a common cache per every host instance or per every Cache Mediator pair (i.e.
- true - The
collectorattribute's value as
truespecifies that the mediator instance is a response collection instance.
- false - The
collectorattribute's value as
falsespecifies that it's a cache serving instance.
- true - The
- maxMessageSize - An optional attribute, which specifies the maximum size of a message to be cached in bytes and defaults to unlimited.
- implementation - The attribute, which defines if the cache is disk or memory based.
- maxSize - The attribute, which defines the maximum number of elements to be cached.
The following Cache Mediator options are available:
Cache Mediator General Options
- Cache Id - Id for cache configuration.
You should have the same id for a cache mediator instance in incoming path and the corresponding mediator instance in outgoing message path.
- Cache Scope -Scope of the cache.
- Per-Host - The cache is kept only for the current host in a cluster.
Per-Mediator - The cache is kept once for the whole cluster.
Distributed caching is not supported for ESB 4.8.0. It is only supported from ESB 4.9.0 onwards.
- Cache Type -Whether the mediator is in the incoming path (check request) or the outgoing path (cache the response).
- Finder - Sets if the message is in an incoming path. This indicates the mediator to find for the request hash of each incoming message.
- Collector - Sets if the message is in outgoing path. This indicates the mediator to collect the response message in the cache.
Hash Generator -The logic for finding the hash which checks against each incoming message.
- Cache Timeout - The cache timeout (the time to keep the cache before it expires) in seconds.
- Maximum Message Size - The limit of the message to cache in bytes.
Cash Implementation Details
- Implementation Type - Currently only "In-Memory" is available.
Default 1000 bytes
On Cache Hit
Specify the sequence to follow when the Cache mediator is hit. You can either specify it as anonymous, where you can define child mediators for the Cache mediator, or you can refer to a named sequence of mediators from the Configuration Registry or Governance Registry.
You can configure the Mediator using XML. Click on "switch to source view" in the "Mediator" window.
In this example, the first message is sent to the endpoint specified as cache is not hit. The response will come to the Cache Mediator inside the out mediator, which caches the response. The second similar message will match the cache and the response will be directly fetched from the cache and sent to the requester. This happens because no
onCacheHit sequence is defined.