Coherence Replicated Cache Scheme Performance Is Drastically Down When Lease Issuer and Lease Requester Not The Same Node In the Cluster. (Doc ID 2255873.1)

Last updated on AUGUST 22, 2024

Applies to:

Symptoms

A user has a replicated cache composed of two java processes. The first process (InsertProcess) creates 10000 objects in the cache and continuously updates them, the second process (DataObserver) prints the update rate observed by a simple EventPrinter implementing the MapListener interface. 

If the user starts the InsertProcess and the DataObserver on two different machines, User noticed that at full speed the InsertProcess performs ~24000 updates/s. If the user stops and restarts the InsertProcess on the same machine, updates drop at a rate of ~900 updates/s. It looks like there is a kind of data ownership concept according to with the process (the cluster member) that created the set of objects. Is there a way to move the ownership of a set of objects from a cluster member to another one? In an alternative, is there a way to move each single object ownership to the cluster member which made the last update?

More precisely the test is as follows:

This customer reported a performance issue with a replicated scheme, in this case, there are two members forming a cluster (A CacheFactory client does inserts into the cache and a CacheFactory client is a MapListener that does calculate the updates rate in the entryUpdate() method). The MapListener member reporting TPS at a lower rate when Map writer/insert client member got restart from the cluster. We know every replicated cache is completely mirrored between all nodes of the cluster, but the problem is that there's a kind of data ownership which makes the performance poor when updating data created on another member earlier. Let me put this as below given. 

1. Start a cluster member that does write replicated case
2. Start a cluster member that does listen for Map events. (Storage enabled)
3. Stop and restart the member that does writing to the Map
4. You start seeing the member that does listen for Map events slows down. The no. of writes per unit time gone down after restarting of a member.
  
Is replicated cache partition owner ship (lease) got changed to Map Listener client when the writing member got restarted? How to improve the performance if this is expected behaviour?

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.