Improving Performance with Cache Scope in Mule Application

Improving Performance with Cache in Mule Application

Caching:Caching is all about application performance optimization ,cache can be very useful in gaining fast application performance .

Cache scope is one of the scope in mule which saves on time and processing load by storing and reusing frequently called data in the memory, file system or database which saves processing time and load if it would have to be access from original source location every time.We can put any number of message processors into a cache scope and configure the caching strategy to store the responses (which contain the payload of the response message) produced by the scope’s subflow.

Even though mule has its default caching strategy its recommended to define the global caching strategy because The default caching strategy uses an InMemoryObject store and should only be used for testing;

Implementation Without Cache:

When an end user of a flight booking system is looking for the flight information between Delhi to Kolkata for a particular date, it then goes through the processing of various steps where it connects to multiple vendors to collect the flight details. Finally after collecting all the details the response will be returned to the user. Same processing steps will be executed for each incoming requests even if multiple users are looking for the same information. Which means if we receive 100 requests for the same source and destination search for a particular date, then all of the processing (steps) will be done 100 times.

Implementation With Cache:

Once the application receives the search request between Delhi to Kolkata for a particular date the response that has been returned to the user will be stored in a cache and for all of the next searches for the same source and destination for that particular date the result can just be returned from the cache without executing the same steps repititively.

Image title

how it works?

Mule sends a message into the cache scope and the parent flow expects an output. The cache scope processes the message, delivers the output to the parent flow and saves the output (i.e. caches the response). The next time Mule sends the same kind of message into the cache scope, the cache scope may offer a cached response rather than invoking, again, a potentially time-consuming process.

Each item in the cache is a key/value pair where the key represents the payload at the cache scope entry point. The value is the result at the end of the cache scope.By default, Mule uses SHA256KeyGenerator and a SHA256 digest to generate a key on the payload. For the cache entry value, Mule will cache not just the payload at the end of the cache scope, but the whole MuleEvent. The idea behind all of this is that apart from the payload, you might need other information such as message properties.

Use Case of Cache:

You can use a cache scope to reduce the processing load on the Mule instance and speed up message processing within a flow. It is particularly effective for:

1)Processing repeated requests for the same information.

2)Processing requests for information that involve large, non-consumable message payloads.

Configuring an Object Store for Cache

By default, Mule stores all cached responses in an InMemoryObjectStore. Below are the multiple ways of creating a caching strategy and define a new object store if you want to customize the way Mule stores cached responses.

  • custom-object-store:Custom object stores are useful when you want to use a custom persistence mechanism for your ObjectStore’s
  • In-memory: This store the data inside system memory. The data stored with In-memory is non-persistent which means in case of application restart or crash, the data been cached will be lost.
  • Managed-store: This stores the data in a place defined by ListableObjectStore. The data stored with Managed-store is persistent which means in case of application restart or crash, the data been cached will no be lost.
  • Simple-test-file-store:This stores the data in a file. The data stored with Simple-test-file-store configuration is persistent which means in case of application restart or crash, the data been cached will no be lost.

Image title

Invalidating a Cache

Mule provides the InvalidatableCachingStrategy interface, which allows you to invalidate a complete cache or a cache key without the need for custom code or configuration.

There are two message processors for invalidating caches:

  invalidate-cache – Completely invalidates a cache. Must reference an invalidatable caching strategy.

<ee:invalidate-cache cachingStrategy-ref=”InvalidatableCachingStrategy”/>

invalidate-key – Calculates a cache key from the current event, then searches for it in the cache and removes it if present. Must reference an invalidatable caching strategy and, optionally, a MuleEventKeyGenerator. If no MuleEventKeyGenerator is provided, Mule uses the default implementation (SHA256MuleEventKeyGenerator).

<ee:invalidate-key cachingStrategy-ref=”InvalidatableCachingStrategy” keyGenerator-ref=”MD5MuleEventKeyGenerator”/>

Let’s walk through how to use Cache scope in mule application.
In this example flow “cachFlow” will be invoked through REST client . All of the steps including message processor’s in the cache scope will be executed for the first request made for ID= 1 and response will be returned to the user. The same will be stored in a cache which will be used to return response hereafter for all of the subsequent requests made for the same ID without executing the message processor in the cache scope.

Flow :

Image title


<?xml version=”1.0″ encoding=”UTF-8″?>
<mule xmlns:dw=”;
xmlns:http=”; xmlns:cxf=”;
xmlns:ee=”; xmlns=”;
xmlns:spring=”; xmlns:xsi=”;

name=”CacheStrategy” doc:name=”Caching Strategy” keyGenerationExpression=”#[]”>
<in-memory-store name=”inMemooryStore” maxEntries=”200″ entryTTL=”20000″ expirationInterval=”20000″/>
<db:generic-config name=”Generic_Database_Configuration”
url=”jdbc:hsqldb:hsql://localhost:9001″ driverClassName=”org.hsqldb.jdbcDriver”
doc:name=”Generic Database Configuration” />
<http:listener-config name=”HTTP_Listener_Configuration”
host=”localhost” port=”8081″ basePath=”/cache” doc:name=”HTTP Listener Configuration” />

<flow name=”cacheFlow”>
<http:listener config-ref=”HTTP_Listener_Configuration”
path=”/cache” doc:name=”HTTP” />
doc:name=”Byte Array to String” />
<set-variable variableName=”id” value=”#[message.inboundProperties.’http.query.params’.id]” doc:name=”Variable”/>
<logger level=”INFO” message=”#[]” doc:name=”Logger”/>
<ee:cache doc:name=”Cache” cachingStrategy-ref=”CacheStrategy”>
<logger level=”INFO” message=”Before calling the GET Flights Info” doc:name=”Logger” />
<db:select config-ref=”Generic_Database_Configuration”
doc:name=”Save to fgwy_user_role”>
<db:dynamic-query><![CDATA[select id,name from employee where id=’#[]’]]></db:dynamic-query>
<logger level=”INFO” message=”After calling the GET Flights Info” doc:name=”Logger” />
<dw:transform-message doc:name=”Transform Message”>
<dw:set-payload><![CDATA[%dw 1.0
%output application/json

payload map ((payload01 , indexOfPayload01) -> {
<logger level=”INFO” message=”#[payload]” doc:name=”Logger” />


Request URL:


Image title

Hope this helps


Ankit Lawaniya

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s