FAQ: Object Store v2
Object Store v2 is available in every region where Runtime Manager (CloudHub) apps can be deployed.
Mule runtime engine 3.8.5 and later
All Mule runtime engine 4.x versions
Mule 4 supports only Object Store v2.
No, only apps deployed to CloudHub can use Object Store v2 or Object Store v1.
For on-premises deployments, you can use the object store included in Mule. For information about the Mule object store, see Store Application Data Using Object Stores.
To view API request data, see View Usage Graphs.
An Object Store v2 subscription pack allows up to 100 million transactions per month for an Anypoint Platform organization. This limit is applied across all Production and non-Production environments. You can use the Object Store v2 Stats API to monitor usage.
If your usage exceeds your license limit, Object Store v2 continues to work. MuleSoft notifies your account administrator and team with any billing-related information.
Yes, Object Store v2 is in the same region as the worker where the app is initially deployed. For example, if you deploy to the Singapore region, the object store persists in the Singapore region.
|If after the first deploy, you move the app to a different region, Object Store v2 remains in the original region to avoid data loss. Your use of Object Store v2 never moves from one region to another. When you need to deploy both an app and object store to a different region, delete the app and re-upload the app into the new region. This action loses all the data that may exist in the storage.|
Object Store v2 is a remote service that is separate from CloudHub workers. All entries that you put in
_defaultUserObjectStore are available to all workers for the same app. If not using
_defaultUserObjectStore, then the data is put into an in-memory object store on the worker and that data is lost if the worker restarts or a new app version is deployed.
For an example of entry availability, if you had 50 entries and 5 workers, all 50 entries would be available to all the workers in the app and the Object Store v2 service handles storing all the data without any impact on the workers.
You can configure a Mule app to use the Object Store REST API to store and retrieve values from an object store in another Mule app.
However, Object Store v2 is not designed for app-to-app communication. To share data between two Mule 4 apps, use a queue in Anypoint MQ.
For information about object store limitations, see Object Store Limitations.
For information about the Object Store REST API, see Object Store v2 API on Exchange.
The total size of an object store is not limited, but each value is limited to 10 MB. The free version also limits usage to 10 transactions per second (TPS) per app. Premium add-on users are allowed up to 100 TPS per app.
In Object Store v2, there is no limit on the number of keys per app.
You can use partitions to divide the object store into separate areas for your stored and retrieved keys. Partitions are logical, rather than physical, structures. For this reason, data access time is the same, whether you store keys in one partition or multiple partitions.
The maximum TTL (time to live) is 2592000 seconds (30 days).
entryTtl value, specified in the global configuration parameters for the connector,
determines when to evict key-value pairs from the store.
The TTL can be either rolling or static:
Accessing the data extends the TTL for 30 days.
The minimum rolling TTL is 1 second. The maximum rolling TTL is unlimited as long as the data continues to be accessed.
The value of
entryTtldetermines when the data is evicted.
The minimum static TTL is 1 second. The maximum (and default) static TTL is 2592000 seconds (30 days). If the
entryTtlvalue is greater than 30 days, TTL is set to the maximum value of 2592000 seconds (30 days) without returning an error.
If the app doesn’t specify a value for
entryTtl, the default value depends on the Mule version.
Mule versions 4.2.1 and later:
Object stores have a rolling TTL by default.
If the data is accessed at least once a week, the TTL is extended for 30 days. Otherwise, it is evicted in the next 7 to 30 days from the most recent expiration date.
Rolling TTL is available for all apps using Mule version 4.2.1 and later.
Mule versions earlier than 4.2.1:
Object stores have a static TTL of 30 days by default.
For information about configuring TTL, see Configure a Custom Time to Live Period.
Anypoint Exchange provides assets for the Mule 3 Object Store connector used by Anypoint Studio 6, and for the Mule 4 Object Store connector used by Studio 7.
All versions of Mule’s Object Store Connector work with both Object Store v1 and Object Store v2.
When you view an Object Store key in Runtime Manager, the value for the key displays as
[binary value] BINARY.
Mule 4 wraps values into a Mule object that causes them to be only visible in binary through Anypoint Platform. Behind the scenes, Mule 4 executes binary serialization with the Mule internal serializer. The user interface cannot deserialize the object, hence it can only tell you that the value is now binary in the user interface.
To view the key value, you need an Object Store retrieve flow in your app’s connector, such as:
<flow name="Retrieve" > <http:listener doc:name="Listener" config-ref="HTTP_Listener_config1" path="/retrieve"> <ee:repeatable-file-store-stream /> </http:listener> <os:retrieve doc:name="Retrieve" key="#[attributes.queryParams.key]" objectStore="Object_store1"/> </flow>
For more information, see Tutorial: Create a Studio 7 Project.
Customers who have not purchased a separate Object Store SKU are rate limited to 10 transactions per second per app. If an app for an account that has not purchased the Object Store v2 SKU exceeds the rate limit, further requests are not processed for a time and a 429 HTTP error status code results. To go beyond the base 10 TPS rate limit, contact your MuleSoft account team.
Object Store v2 uses TLS for secure transport. Data at rest is stored using FIPS 140-2 compliant encryption standards. If you require a higher level of security, we recommend that you encrypt sensitive data before writing it to the Object Store.
Object Store v2 performs I/O for each read and write. With Object Store v2, the API call is localized to the same data center as the Runtime Manager app.