Caching in mule ESB can be done by Mule Cache Scope. Mule Cache Scope has 3 storage types –
In-memory:
This store the data inside system memory. The data stored with In-memory is non-persistent which means in case of API restart or crash, the data been cached will be lost.
Configuration Propertied
1)Store Name
2)Maximum number of entries
3)TTL (Time to live)
4)Expiration Interval
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 API restart or crash, the data been cached will no be lost.
Configuration Propertied
1)Store Name
2)Maximum number of entries
3)TTL (Time to live)
4)Expiration Interval
5)Persistence (true/false)
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 API restart or crash, the data been cached will no be lost.
Configuration Propertied
1)Store Name
2)Maximum number of entries
3)TTL (Time to live)
4)Expiration Interval
5)Persistence (true/false)
6)Name and location of the file
Default Caching Strategy
By default, all cache scopes in Mule applications follow the caching strategy procedure described below.
The default caching strategy uses an InMemoryObjectStore and should only be used for testing; on actual implementations, follow the instructions in Creating a Caching Strategy.
A message enters the cache scope.
Cache scope determines whether the message’s payload is consumable. A consumable payload can only be read once before it is lost – such as a streaming payload – and cannot be cached.
If the message payload is consumable, cache scope always processes the message; nothing is cached and the caching strategy is abandoned.
If the message payload is not consumable, cache scope continues to the next step in the caching strategy.
Cache scope generates a key to identify the message’s payload. Mule uses an SHA256KeyGenerator and a SHA256 digest to generate a unique key for the message payload.
Cache scope compares the newly-generated key to cached responses that it has previously processed and saved in an InMemoryObjectStore — a container for cached data. In other words, cache scope searches for a “cache hit” it can offer instead of processing the message.
Where there is a cache miss, cache scope processes the new message and produces a response. Cache scope also saves the resulting response in the object store. (If the response has a consumable payload, it does not cache the response.)
Where there is a cache hit, the caching strategy uses a DefaultResponseGenerator to generate a response that combines data from both the new request and the cached response. (If the generated response has a consumable payload, it does not cache the response.)
Cache scope pushes the response out into the parent flow for continued processing.
Object Stores and Clustering
In Mule 3.4.1 and earlier versions, if you created a caching strategy without configuring an object store, Mule created a default InMemoryObjectStore which did not work as a unified cache for all cluster nodes. Instead, each node had its own cache; to create a unified cache for the cluster it was necessary to configure the application to use a custom managed store.
Starting in Mule 3.5.0, by default new caching strategies use an object store instance that provides a unified cache for all cluster nodes without extra modifications. The exception is the default caching strategy used by the Cache Scope, which uses the InMemoryObjectStore and is intended for testing only.
Do not use TextFileObjectStore for a cache as the cache contains more than text content. For a list of all object store types, see the mule.util.store package summary. Mule provides the MuleObjectStoreManager, which creates object stores.
If you want to enable the old behavior on your caching strategy (that is, provide a cache for each cluster node), you need to configure your application to use a managed store that controls an in-memory store. The configuration for the managed store should be:
maxEntries: 4000
entryTTL: -1
expirationInterval: 1000
For details on configuring caching strategies, see Creating a Caching Strategy.
Adding and Configuring a Cache Scope
Drag and drop the cache scope icon from the palette into a flow on your canvas.
Drag one or more processors from the palette into the cache scope to build a chain of processors to which Mule applies the caching strategy. A cache scope can contain any number of message processors.
Field Descriptions
Display Name field - Value is Cache - Customize to display a unique name for the scope in your application.
Example: doc:name="Cache"
Caching strategy reference
Use Default caching strategy (Default) - Select if you want the cache scope to follow Mule’s Default Caching Strategy.
Reference to a strategy - Select to configure the cache scope to follow a global caching strategy that you have created; select the global caching strategy from the drop-down menu or create one by clicking the green plus sign.
Example: cachingStrategy-ref="Caching_Strategy"
Filter field:
Process all messages (Default) - Select if you want the cache scope to execute the caching strategy for all messages that enter the scope.
Filter messages using an expression - Select if you want the cache scope to execute the caching strategy ONLY for messages that match the expression(s) defined in this field.
If the message matches the expression(s), Mule executes the caching strategy.
If the message does not match expression(s), Mule processes the message through all message processors within the cache scope; Mule never saves nor offers cached responses.
Example: filterExpression="#[user.isPremium()]"
Filter messages using a global filter - Select if you want the cache scope to execute the caching strategy only for messages that successfully pass through the designated global filter.
If the message passes through filter, Mule executes the caching strategy.
If the message fails to pass through filter, Mule processes the message through all message processors within the cache scope; Mule never saves nor offers cached responses.
Example: filter-ref="MyGlobalFilter"
Creating a Caching Strategy
The default caching strategy used by the cache scope uses an InMemoryObjectStore, and is only suitable for testing. For example, processing messages with large payloads may quickly exhaust memory storage and slow the processing performance of the flow. In such a case, you may wish to create a global caching strategy that stores cached responses in a different type of object store and prevents memory exhaustion.
In the Cache properties editor, click the radio button next to the Reference to a strategy field, and click the green plus sign.
Configure the fields in the Global Element Properties panel that appears according to the tables below. The only required field is Name.
caching_strategy_general
Field Descriptions
Name -Caching_Strategy - Customize to create a unique name for your global caching strategy.
Example: name="Caching_Strategy"
Object Store - (Optional) Configure an object store in which Mule stores all of the scope’s cached responses. Refer to the Configuring an Object Store for Cache section below for configuration specifics. Unless otherwise configured, Mule stores all cached responses in an InMemoryObjectStore by default.
Example:
Event Key:
Default - (Default) Mule utilizes an SHA256KeyGenerator and a SHA256 digest to generate a key. Use when you have objects that return the same SHA256 hashcode for instances that represent the same value, such as String class.
Key Expression - (Optional) Enter an expression that Mule should use to generate a key. Use when request classes do not return the same SHA256 hashcode for objects that represent the same value.
Example: keyGenerationExpression="#[some.expression]"
Key Generator - (Optional) Identify a custom-built Spring bean that generates a key. Use when request classes do not return the same SHA256 hashcode for objects that represent the same value. If you have not created any custom key generators, the Key Generator drop-down box is empty. Click the green plus sign next to the field to create one.
Example: keyGenerator-ref="Bean"
Advanced Configuration
Optionally, click the Advanced tab in the Global Element Properties panel and configure further, if needed, according to the tables below.
caching_strategy_advanced
Field Descriptions
Response Generator - Specify the name of a Response Generator that directs the cache strategy to use a custom-built Spring bean to generate a response that combines data from both the new request and the cached response. Click the green plus sign next to the field to create a new Spring bean for your caching strategy to reference.
Example: responseGenerator-ref="Bean1"
Consumable Message Filter - Specify the name of a Consumable Message Filter to direct the cache strategy to use a custom-built Spring bean to detect whether a message contains a consumable payload. Click the green plus sign next to the field to create a new Spring bean for your caching strategy to reference.
Example: consumableFilter-ref="Bean2"
Event Copy Strategy:
Simple event copy strategy (data is immutable) - Data is either immutable, like a String, or the Mule flow has not mutated the data. The payload that Mule caches is the same as that returned by the flow. Every generated response contains the same payload.
Serializable event copy strategy (data is mutable) - Data is mutable or the Mule flow has mutated the data. The payload that Mule caches is not the same as that returned by the flow, which has been serialized/deserialized in order to create a new copy of the object. Every generated response contains a new payload.
Example:
Configuring an Object Store for Cache
By default, Mule stores all cached responses in an InMemoryObjectStore. Create a Caching Strategy and define a new object store if you want to customize the way Mule stores cached responses.
Object Store Description
custom-object-store
Create custom class to instruct Mule where and how to store cached responses.
in-memory-store
Configure the following settings for an object store that saves cached responses in the system memory:
Store name
Maximum number of entries (that is, cached responses)
The “life span” of a cached response within the object store (i.e. time to live)
The expiration interval between polls for expired cached responses
managed-store
Configure the following settings for an object store that saves cached responses in a place defined by ListableObjectStore:
Store name
Persistence of cached responses (true/false)
Maximum number of entries (i.e. cached responses)
The “life span” of a cached response within the object store (i.e. time to live)
The expiration interval between polls for expired cached responses
simple-text-file-store
Configure the following settings for an object store that saves cached responses in file:
Store name
Maximum number of entries (i.e. cached responses)
The “life span” of a cached response within the object store (i.e. time to live)
The expiration interval between polls for expired cached responses
The name and location of the file in which the object store saves cached responses
Configure the settings of your new object store. If you selected a custom-object-store, select or write a class and a Spring property to define the object store. Configure the settings for all other object stores as described in the table below.
Field or Checkbox XML Attribute Instructions
Store Name
name (for in-memory, simple-text)
storeName (for managed)
Enter a unique name for your object store.
Persistent
persistent="true"
Check to ensure that the object store saves cached responses in persistent storage. Default is false.
Max Entries
maxEntries
Enter an integer to limit the number of cached responses the object store saves. When it reaches the maximum number of entries, the object store expunges the cached responses, trimming the first entries (first in, first out) and those which have exceeded their time to live.
Entry TTL
entryTTL
(Time To Live) Enter an integer to indicate the number of milliseconds that a cached response has to live in the object store before it is expunged.
Expiration Interval
expirationInterval
Enter an integer to indicate, in milliseconds, the frequency with which the object store checks for cached response events it should expunge. For example, if you enter “1000”, the object store reviews all cached response events every one thousand milliseconds to see which ones have exceeded their Time To Live and should be expunged.
Directory
directory
Enter the file path of the file where object store saves cached responses.
Synchronizing a Caching Strategy
Mule allows synchronizing access to a cache, which can avoid unexpected results if two different threads (on the same or on different Mule instances) use the cache at the same time.
For example: two threads attempt to retrieve a value from a cache, but do not find the value in the cache. So each thread calculates the value independently and inserts it into the cache. The value inserted by the second thread overwrites the value inserted by the first thread. If the values are different, then two different answers would be obtained for the same input, with the last one stored in the cache.
In some scenarios this is perfectly valid, but it can be a problem if the application requires cache coherence. Synchronizing the caching strategy ensures this coherence. A synchronized cache is locked when it is being modified by a thread. In the example mentioned above, a locked cache would force the second thread to wait until the first thread has calculated the value, and then retrieve the value from the cache.
Synchronization affects performance, so it is recommended to disable it unless needed. Note that performance degradation is most severe in cluster mode.
To enable synchronization, use the synchronized property in the caching strategy element. Accepted values are true and false.
