When working with WebCenter Spaces it is recommended to configure the Java Object Cache (JOC) to increase performance as described in following section of the Enterprise Deployment Guide.
In a clustered environment the JOC is responsible for synchronizing java objects between managed servers in the cluster.
The JOC has a distributor per machine which will distribute the java objects to the other machines in the cluster.
The document states that you need to configure the JOC for each Spaces managed server by running the python script specified in the documentation.
Depending on the topology of your cluster this might cause stuck threads!
Whenever your cluster has more than 1 WebCenter Spaces managed server on the same machine you have to change the JOC configuration created by the script.
The reason for this is that the script will create a JOC distributor per managed server which is a bad practice. Each machine should have at most 1 distributor. Therefore all WebCenter Spaces managed servers on the same machine should use the same JOC configuration.
Let's clarify this with an example.
Suppose we have a topology where WebCenter Spaces is configured in a cluster of 2 machines and each machine will have 2 managed server as shown in following diagram:
When you run the python script to create the JOC configuration and enable distribution you will end up with 4 different JOC configuration files which can be found in
<domain_home>/config/fmwconfig/servers/WC_SpacesX/javacache.xml where X is the number of the instance.<?xml version="1.0" encoding="UTF-8" standalone="yes"?><cache-configuration xmlns="http://www.oracle.com/oracle/ias/cache/configuration11" max-objects="5000" max-size="10" private="false" cache-dump-path="jocdump" system="false" clean-interval="60"><communicationService enabled="true"><v2 ssl-config-file=".sslConfig" init-retry="300" init-retry-delay="2000" enable-ssl="false" auto-recover="false"><packet-distributor enable-router="false" startable="true" dedicated-coordinator="false"><listener-address host="host1" port="9988" ssl="true"/><distributor-location host="host1" port="9988" ssl="true"/><distributor-location host="host2" port="9988" ssl="true"/><distributor-location host="host1" port="9987" ssl="true"/><distributor-location host="host2" port="9987" ssl="true"/></packet-distributor></v2></communicationService><diskCache size="10" ping-interval="60"/><logging override-parent="false" location="javacache.log" default-level="SEVERE"/><dms enabled="false"/></cache-configuration>
Notice that each configuration will have a different listener-address and has 4 distributors in it's list. This is deemed to cause stuck threads and can cause your managed servers to crash.
The correct configuration for this type of cluster is the following:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?><cache-configuration xmlns="http://www.oracle.com/oracle/ias/cache/configuration11" max-objects="5000" max-size="10" private="false" cache-dump-path="jocdump" system="false" clean-interval="60"><communicationService enabled="true"><v2 ssl-config-file=".sslConfig" init-retry="300" init-retry-delay="2000" enable-ssl="false" auto-recover="false"><packet-distributor enable-router="false" startable="true" dedicated-coordinator="false"><listener-address host="host1" port="9988" ssl="true" /><distributor-location host="host1" port="9988" ssl="true" /><distributor-location host="host2" port="9988" ssl="true" /></packet-distributor></v2></communicationService><diskCache size="10" ping-interval="60" /><logging override-parent="false" location="javacache.log" default-level="SEVERE" /><dms enabled="false" /></cache-configuration>
Their should be no difference between the javacache.xml from WC_Spaces1 and WC_Spaces2 WC_Spaces3 and WC_Spaces4 should also use the same file but in that file the listener address should be host2 instead of host1.
Further information can be found in the Oracle Fusion Middleware High Availability Guide in the Configuring the Distributed Java Object Cache section.