2 Known Problems and Workarounds

known problems at the time of release.

This chapter includes the following sections:

2.1 Changing the Partition Count When Using Active Persistence

The partition count cannot be changed when using active persistence. If you change a services partition count, then on restart of the services all active data is moved to the persistence trash and must be recovered after the original partition count is restored. Data that is persisted can only be recovered to services running with the same partition count.

Ensure that the partition count is not modified if active persistence is being used. If the partition count is changed, then a message similar to the following is displayed when the services are started:

<Warning> (thread=DistributedCache:DistributedCachePersistence, member=1):
Failed to recover partition 0 from SafeBerkeleyDBStore(...); partition-count
mismatch 501(persisted) != 277(service); reinstate persistent store from
trash once validation errors have been resolved

The message indicates that the change in the partition-count is not supported and the current active data has been copied to the trash directory. To recover the data:

  1. Shutdown the entire cluster.

  2. Remove the current active directory contents for the cluster and service affected on each cluster member.

  3. Copy (recursively) the contents of the trash directory for each service to the active directory.

  4. Restore the partition count to the original value.

  5. Restart the cluster.

2.2 Inconsistent Data in Federated Caches During Snapshot Recovery

There is a known issue that can result in inconsistent data when using federated caching together with cache persistence. Currently, a recovered snapshot of a service is not propagated to federated clusters. The cached data on the originating cluster is recovered, but the cache data on the destination cluster may still contain the cached data that was present prior to the recovery. Support for this use case is scheduled for the next patch release.

2.3 ClassNotFoundException with Coherence REST on WebLogic Server

There is a known issue where classes for user types are not found at runtime when a Coherence REST application is deployed to WebLogic Sever and coherence-rest.jar is on the server classpath.

To work around this issue:

  1. Rename the COHERENCE_HOME/lib/coherence-rest.jar library to coherence-ext-rest.jar.

  2. Include the COHERENCE_HOME/lib/coherence-ext-rest.jar library in the application classpath so the application compiles.

  3. Package the coherence-ext-rest.jar library in the Coherence REST application WAR module.

  4. Deploy the Coherence REST application.

2.4 Impact of Generics

  • Care should be taken to ensure that federated caches across a federation are configured to use the same types as no runtime-type-checking is performed between clusters in a federation.

  • Care should be taken to ensure that recoverable caches are consistently configured to use the same types during restarts as no runtime-type-checking is performed.

2.5 Support for JVisualVM Plugin

The Coherence JvisualVM Plugin is supported for Coherence 3.7.1.X and above. Using the plugin to connect to older clusters is not supported.