This content has been marked as final. Show 5 replies
Coherence* Extend provides lot more operation flexibility at the cost of slight performance because the communication protocol changes from TCMP to TCP and an extra hop. Here are some of the advantages of using C*Extend:
- Client application (weblogic in your case) and coherence servers can run different coherence versions and can be upgraded independently
- Client and server configuration can be managed independently
- Data Access can be secured more efficiently
- Client application and servers can reside across subnets and WANs
Some of the disadvantages of using C*Extend:
- Extra hop that occurs through the proxy
- Extra JVM and hardware to run and manage proxies including, load balancing proxies, memory allocation for proxies, number of proxies and so on.
- Increased latency due to an extra hop and use of TCP compared to TCMP.
I would recommend to use C*Extend if:
1) client application(s) may join and/or leave the coherence cluster frequently (common reason is client application performing frequent long GCs)
2) client application(s) does not reside in the same subnet as the coherence servers
3) client application(s) are not tightly bound at an application layer to the coherence cluster.
4) client application(s) and coherence servers are managed by two different groups and may have have different upgrade schedules.
5) Requires data access security between client application(s) and coherence servers.
Specifically, for your use case,
1) If all your applications are sharing the same data in a single Coherence cluster then I would recommend you to go with C*Extend to decouple the applications from each other.
2) If your applications and coherence cluster are independently managed then go with Coherence Extend
Hope this helps!
If we do care about performance, is it a good practice to run so many storage disabled members in the cluster?Yes, if you can ensure client applications can behave as good citizens (no frequent connect/disconnect from cluster). Reconnects and disconnects can make your cluster unstable because:
Every member of the cluster (storage disabled/enabled) node has the knowledge of the hash bucket used to determine where the data for a key is stored. On reconnect this knowledge has to be initialised again. Also, a lot of communication happen within the cluster members for identifying the death of the cluster member which is critical for Coherence to function correctly.
If you can be certain about the duration of the longest GC you can configure Coherence (heartbeat/timeout) parameters to handle GCs more gracefully.
Hope this helps!