As API usage is growing day by day, we are experiencing more load on the CloudHub workers resulting in performance issues. To achieve the same load and resolve the performance bottleneck on a smaller number of vCores in CloudHub, Mule has Cache Scope. Cache Scope saves time and processing load by storing and reusing frequently called data in the memory, file system and database instead of loading the data from the backend systems, which usually takes more processing time. You 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 processing that occurs within the scope. Caching is all about application performance optimisation, and can be very useful in gaining fast application performance.
By default, Anypoint Platform CloudHub does not provide a transparent distributed cache scheme. The typical cache scope on a Mule flow works fine when deployed on a mule standalone cluster , but when the same application is deployed on the CloudHub, only the publisher node is able to consume the original payload from the cache, while the others fails to retrieve the cached content, resulting in a cache miss. Each worker is a dedicated instance of Mule that runs your integration application. Workers may have a different memory capacity and processing power depending on how you configure them at application level. Workers can be scaled vertically and horizontally, If we scale the Workers horizontally then this behaviour is expected CloudHub because CloudHub workers are not clustered. As the default in-memory ObjectStore is intended to be used across a cluster through hazelcast replication as the backend mechanism, it fails when deployed on CloudHub
It is still possible to implement a distributed cache mechanism by using the default CloudHub persistent Object Store (Using Object Store V2), which is automatically registered under the _defaultUserObjectStore bean name on spring.
A second issue is on the Cache scope implementation with CloudHub itself, where it is possible to define a specific Caching strategy, but not reference the _defaultUserObjectStore by a simple reference to a bean. But, we can still achieve this by defining a custom object store which acts as a wrapper for the underlying _defaultUserObjectStore default CloudHub Object Store, storing and retrieving elements against it, and exposing the interfaces to the mule flow.
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 defining a new object store if you want to customise 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.
- In-memory: This stores the data inside system memory. The data stored with In-memory is non-persistent, which means in case of an application restart or crash, the cached data 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 an application restart or crash, the cached data will not be lost.
- Simple-test-file-store: This stores the data in a file. The data stored with the Simple-test-file-store configuration is persistent, which means in case of an application restart or crash, the cached data will not be lost.
Configuring Cache Strategy with ‘custom-object-store’
Below is the reference example of how to add custom object store using cache scope:
- Place the Cache Scope component to the mule flow
- Select the object custom-object-store from the list of available stores
- Select the CustomObjectStore Java class and provide the values for the entryTTL, expirationInterval and localObjectStore
- Code snippet
Define the Custom Object Store
Below is the example of how to implement Custom Object Store by extending the Abstract Monitored Object Store.
The Caching Strategy which is defined under the cache scope provides the main functionality, which implements the cache through a custom ObjectStore using custom classes. You can see that three properties using the custom ObjectStore:
- entryTTL: the time to live on objects, expressed in milliseconds
- expirationInterval: the interval at which the cache entries are scanned for expired entries
- localObjectStore: it references to the “_defaultUserObjectStore” under Object Store V2
Deploy Your Application in Anypoint Platform
- In Studio, right-click your application’s name in Package Explorer and click Anypoint Platform > Deploy to Cloud.
- At the User login window, specify your Anypoint Platform username and password, and click Sign in
- In Runtime Manager, specify an application name. Each name is unique and becomes the URL by which your application is available in Runtime Manager. The URL has the APPLICATION_NAME.cloudhub.io format where your application resides in the cloudhub.io name space. Ensure the application name gets a green check mark for proper naming and being unique.
- Set the Runtime Version to Mule 3.9.1 and later. Ensure that the Runtime exposes the Use Object Store v2 checkbox.
- Click the Use Object Store v2 checkbox.
- After configuring your application, click Deploy Application.
- In the Runtime Manager deploy window, wait until a message displays with a green dot and the message that your application successfully deployed to CloudHub.
- Click Open in Browser and Close Window.
- In Runtime Manager, click the right side of your application’s entry to view its details.
- Click Manage Application. In the application’s settings screen, note that Object Store appears in the left side navigation area. The former label Application Data is now called Object Store for OSv2.
Test the Application
- Develop a simple Mule application with two flows having HTTP Get and Post method where Post method will store the Key’s value inside the custom object store through Object Store V2 and the Get method will be used to get the value of the Key from the Cache through the Object Store V2.
- Use Postman to trigger the APIs which we have developed with two HTTP methods – Get (Retrieve Operation) and Post (Store Operation).
- A store operation, reachable on http://host:port/store?key=<KEY for cache>, which stores the payload under the corresponding KEY on the underlying caching implementation.
- A retrieve operation, reachable on http://host:port/retrieve?key=<KEY for cache>, which retrieves payload from cache looking up at the key on the underlying caching implementation.
Viewing Data in the Object Store
- Log into Anypoint Platform and click Runtime Manager.
- Click the name of your application to view the application’s dashboard.
- Click Object Store from the left navigation bar
- The default Object Store name is “_defaultUserObjectStore”.
- The columns show the Object Store name, partition name, key, and key data. The partition groups object store keys.
- Click the Object Store name, partition name, and key to view its value.
- To delete a key, hover over a key name, and click the trash can icon. Similarly, you can delete a partition or the store itself by hovering and clicking the trash can icon.
Object Store v2 provides following features
- Object Store v2 keys persist for 30 days unless updated
- Supports unlimited keys.
- Fully integrated with the Anypoint Platform.
- Object Store v2 keys HA is available in all supported regions and availability zones within each region.
- Object Store v2 keys is co-located in the same region as your workers, for example, your workers in Frankfurt would use Object Store v2 keys that is hosted in Frankfurt.
- Data at rest is stored using FIPS 140-2 compliant encryption standards.
- Stores values up to 10 MB in size.
If you would like to find out more about Mule and how API-led connectivity can help you create a fully integrated environment, do give us a call at +44 (0)203 475 7980 or email us at Salesforce@coforge.com
Other useful links:
How to enable Secure Property Placeholder in MuleSoft