Setting up Distributed Caching

As the holiday season sets in, my blogging activity seems to have slowed down :) .

Going back to tech stuff, One of the newer caching functionality implemented through the iAS infrastructure in ERP applications is "Distributed Caching". Though the onus of leveraging on this caching framework for Self-Service Applications is on the application developer/system administrator, it is essential to have the framework setup accurately to enable "Distributed Caching" in implementations wishing to use this feature. However, the upside of having this setup accurately is fewer Jserv errors. Whether we like it or not, the functionality might have crept in "inadvertantly" in the system via the patches applied to the system eg. for a module specific upgrade, to overcome a specific issue or any other reason.

In a nutshell, the following actions must be performed to setup the distributed caching successfully.

1. Apply the appropriate patches:

At the time we implemented this in our environment, we had the following patches:

- 5455628
- 5468797
- 5639951

These patches might have gotten superceded and the recommendation is to stay current on the patches.

2. Entries of interest in jserv.properties

"wrapper.bin.parameters=-DLONG_RUNNING_JVM=true" - This should be set to true.
"wrapper.bin.parameters=-DCACHEMODE=LOCAL" - This should be eliminated completely (typically the autoconfig template would have taken care of this) from the jserv.properties or atleast commented out.

3. Make sure Workflow Components are up and running:

One of the features of "Distributed Caching" is "database invalidation". This comes into play when the data objects cached in the jserv are modified by the forms interface.

So, for this feature to work correctly, we need to have the "Workflow Java Deferred Agent Listener" up and running at a minimum. Ideally, the recommendation is to have all of the workflow background components running.

4. House Keeping Jobs:

- Workflow Control Queue Cleanup
- Workflow Background Process (To Process Deferred, Timeout and Stuck)
- Purge Obsolete Workflow Runtime Data

5. Define the appropriate ports:

- FND_CACHE_PORT_RANGE
- JTF_DIST_CACHE_PORT


FND_CACHE_PORT_RANGE needs to be defined equal to the number of OACoreGroup JVMS that you have. JTF_DIST_CACHE_PORT needs to be defined as well. The default would be 12345. So if you have more than one instance running, you need to set it separately for each instance such that there is no conflict. One way is to add 3000 to the port specified in jserv.properties for OACoreGroup. Eg. 16000+3000=19000

Be Sure to update the values in context file so that the values are preserved across autoconfig runs. If you are not a big fan of running autoconfig for these small changes, then here is what you need to do:

- Update in jserv.properties
- Update the profile options at site level. This would make it consistent across servers ( if you have a multi-node installation)


Congratulations!! You just completed all the steps to setup Distributed Caching Framework. But, how do you know that it is setup accurately? Go on to the next step.

6. Validate:

- Login to OAM
- Click on the “Diagnostics” tab
- In the diagnostics window, under HTML Platform, choose the “test Caching Framework”
- Run this test without prerequisites
- This test should complete with out any errors


-- Aravind Kamath