inCache: Why are some pages with dependencies being cached correctly in remote Satellite Server while other pages with dependencies lose their dependencies and get cached as _NODEP_ ? (Doc ID 1456975.1)

Last updated on OCTOBER 12, 2021

Applies to:

Symptoms

This document only applies to environments with inCache enabled.

WebCenter Sites instances always display the affected pages correctly. The issue is only seen on remote Satellite Server (SS).

If there is more than one remote SS deployed it may appear that some pages are caching correctly with dependencies in one remote SS while at the same time the same pages are caching without dependencies (i.e. _NODEP_ ) in another remote SS.

If this occurs randomly among remote SS instances then there may be a load balancer and a number of instances of remote SS. Simplifying the test case will help isolate and confirm the issue. If there is an intermediate firewall or load balancer, temporarily disable them and confirm if issue persists with a test scenario.

Test the connection from the Sites instance(s) to the remote SS instance(s) (i.e. ping from Sites host machine to remote SS host machine and vice versa) to confirm two-way communication between Sites and SS.

Verify that SystemSatellite table entries are correct for each instance of remote SS:
    i.e. PROTOCOL, HOST, PORT, SATELLITESERVLETPATH, FLUSHSERVLETPATH, INVENTORYSERVLETPATH, USERNAME, PASSWORD

The quickest way to confirm this issue on the environment is by applying the work around. See solution.

If you do not or cannot apply the work around for some reason, you can use the following test scenario in order to reproduce the issue.

1. Choose a test asset which has dependencies in order to track successful or unsuccessful caching.

2. Flush all remote SS.

3. Update the asset with some content (e.g. a timestamp in a text attribute) and publish it.

4. Access the asset from all of the remote SS instances to populate their respective inCache caches and confirm the content has updated and rendered.

5. Update the asset with some new content (new timestamp) and publish the asset.

6. Access the asset from all of the remote SS instances to verify if the content update was successful.

7. Repeat steps 5 and 6 until the content update is unsuccessful on one of the remote SS.

Changes

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.