MuleSoft Object Store — Some Insights
Introduction
In this brief article, we will check some internal functioning of the Object Store (OS) and view it from a different angle. Well, for the brevity of the article, I will keep aside its usage. It's the simplest component to use and the use cases are also simple.
Object Store Implementation
Below is the basic class diagram of Object Store.
The name themselves suggest what they serve.
PartitionedInMemoryObjectStore
When you declare your OS to store data in the JVM memory of the Mule ESB.
PartitionedPersistentObjectStore
When you declare your OS to store data in the local file system.
This class internally invokes PersistentObjectStorePartition which does the actual heavy lifting.
For this article, we are going to focus on the Persistent Object Store.
Where are they located?
They are located in the below jar:
mule-core-4.4.0.jar
The above classes (depending on the persistent type i.e memory or file) are directly invoked when the OS connector is used in a Mule application.
A Small Demo
Source code is the singular truth of software. So, below is a demo code to show how Persistent OS works. I am focusing on the PersistentObjectStorePartition as marked in the class diagram in the previous section.
In the below code, I am trying to use the store connector outside of the Mule ESB.
The above code simply stores a value (i.e Hello World) in a variable called data.
On line 29, there is a method invocation called store(key,value).
This is the actual method of the Object Store that does the actual work for us. The code is quite simple for PersistentObjectStorePartition and you can browse it yourself.
The third argument of the PersistentObjectStorePartition class is a directory where the file containing the key & value actually gets stored. The content of the file is java serialised so it won't make sense to human eyes unless desereialised.
For this local code (outside of Mule ESB), I have specified the directory as my Downloads. In the case of Mule ESB, it's the .mule directory.
Now a Big Question
What happens when you store big objects in the OS?
The answer is explicit. The big size of the data will increase the size of the target file that stores the object. Eventually, this will increase the disk usage of the Mule ESB and the consequence is its slow performance.
Also, let's say the application is having a load of 200 TPS. Think about the I/O operations it will need to access the values stored in the files.
Summing up, it's not an ideal case to store large objects in OS neither in InMemory nor in Persistent object-store.
Conclusion
This is a trivial article on a trivial subject. It's not even necessary to dig too much to know the reasons for not storing huge objects in Object Store. The purpose was solely to explain that there lies a very simple code for the Object Store.
Have fun!!!
