Over a million developers have joined DZone.

WSO2 ESB Cache Mediator Tutorial

DZone's Guide to

WSO2 ESB Cache Mediator Tutorial

· Integration Zone ·
Free Resource

Want to learn more about API monitoring? Learn how Trustpilot monitors over 600 microservices with Runscope on this webinar.

This tutorial is about Caching Responses Over Requests. It means when WSO2 ESB gets the same request then Cache Mediator will send out Caching Responses. In this example I am using my last service that I created from WSO2 DSS.

1. Start DSS (With my last Services/ or any service you wish to used – remote Services) and WSO2 ESB.

2. Create “Pass Through Proxy”


  • Cache Id: Same id for a cache mediator instance in incoming path and the corresponding mediator instance in outgoing message path.
  • Cache Scope: This is important if the service is deployed in a cluster.
    Per-Host: current host in a cluster.
    Per-Mediator: Twhole cluster.
  • Cache Type: Whether the mediator is in the incoming path (check request) or the outgoing path (cache the response).
  • Finder: Set if the message is incoming path. This indicate the mediator find for the request hash of each incoming message.
  • Collector: Set if the message is in outgoing path. This indicate the mediator collect the response message in the cache.
  • Hash Generator: The logic for finding each incoming message.
  • Cache Timeout: expiring time (seconds).
  • Maximum Message Size: The limit of the message to cache in bytes.
  • Implementation Type: Currently only "In-Memory" is available.
  • On Cache Hit: Specify the sequence to follow when the cache mediator is hit. (named sequence of mediators from the registry.)

3. Now add Cache mediator to the proxy.

In Sequence


Out Sequence


4. Try it out


5. Now testing is it coming from cache or not proxy level login

6. Here is my new proxy with logs

<proxy xmlns="http://ws.apache.org/ns/synapse" name="TestingCacheProxy" transports="https,http" statistics="disable" trace="disable" startOnLoad="true">
            <property name="testing" value="Request arrives in to InSequence"/>
         <cache scope="per-host" collector="false" hashGenerator="org.wso2.caching.digest.DOMHASHGenerator" timeout="20" maxMessageSize="500">
            <implementation type="memory" maxSize="1000"/>
            <property name="testing" value="Hi, I am after Cache"/>
               <address uri="http://localhost:9764/services/PostgresDataService?wsdl"/>
            <property name="testing" value="Hi, I in the top of Out Sequence"/>
         <cache scope="per-host" collector="true"/>
            <property name="testing" value="I am in Out Sequence and below the Cache"/>
   <publishWSDL uri="http://localhost:9764/services/PostgresDataService?wsdl"/>

Now call some, and see 



Read line mapping Show the 1st call,

Blue Line shows next call that was respond from cache .

Cache will speed up you systems/proxies. So it is time to use it.

Are your customers the first to know when your API is failing? Watch this webinar to learn how Trustpilot monitors over 600 microservices with Runscope, and are always on top of any API errors.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}