Coherence Clustering Principles
By Dxfelcey-Oracle on Feb 16, 2012
What do we mean by a Coherence Cluster?
- Multi-cast or unicast addresses for locating cluster members
- Cluster identity information
- Management settings
- Networking parameters
- Security information
- Logging information
- Service configuration parameters
These settings are used by Coherence services to communicate with other nodes, to determine cluster membership, for logging and other operational parameters and are similar to the Domain configuration used by Weblogic Server. They also apply to the entire Coherence cluster node, which usually means the whole JVM. Although a cluster node will usually equate to a JVM, it is possible to have more than one node per JVM by loading the Coherence libraries multiple times in different isolated class loaders, e.g. a "child first" class loader. However, this is only usually done within the contaxt of an application server or a test framework.
Which is selected will depend on the mode that Coherence is running in (the default is Developer mode) and can be set using the system property -Dtangosol.coherence.mode=prod.
Note: Its important to ensure that the production mode is selected for production usage, as in production mode certain communication timeouts etc will be extended so that Coherence will wait longer for services to recover – amongst other things.
What is a Coherence Service?
- Connectivity Services
- Clustering Service – manage cluster membership communications. There is exactly one of these services per JVM (or within a class-loader). This service tracks which other nodes are in the cluster, node failures etc.
- Proxy Services – manage external connections into the cluster from “extend” clients
- Processing Services
- Invocation Service – executes processing requests/tasks on the node in the cluster it is running on.
- Data Services
- Distributed Cache Service – manages cache data for caches created from the scheme its defined in
- Replicated Cache Service – provides synchronous replication cache services, where all managed cache data exists on every cluster node
- When the Coherence classes are loaded they will by default search the CLASSPATH for the coherence-cache-config.xml file – which is actually the name specified in the default operational override file. The first instance that is found wild be used. However, if one is specified using the system property –Dtangosol.coherence.cacheconfig=<cache config file> it will use that cache configuration file instead. Also a cache configuration can be explicitly loaded from the CLASSPATH, as follows:
// Load a applicaton X cache configuration fileClassLoader loader = getClass().getClassLoader();// Note: it’s a URI that is specified for the location// of the cache configuration fileConfigurableCacheFactory factory = CacheFactory.getCacheFactoryBuilder.getConfigurableCacheFactory(“applicationx-cache-config”, loader);
NamedCache localCacheInstance = factory.ensureCache("trade-cache", loader);
- When the cache configuration file is parsed distributed cache service threads are started for all the cache “schemes” that are defined if the autostart parameter is set to true (by default its false).
Note: For data services the autostart flag is only observed for distributed caches. So a replicated cache service would automatically be started.
- Each cache service started is given a name - or one is created if none is specified. This service thread then attempts to join with other services that have the same name in the Coherence cluster. If none are found, i.e. it’s the first to start, it will become the “senior member” of the service. To illustrate this take a look at a sample log statement when Coherence starts a service.
2012-02-02 11:00:04.666/16.462 Oracle Coherence GE 22.214.171.124 <D5> (thread=DistributedCache:DefaultDistributedCacheService, member=1): Service DefaultDistributedCacheService joined the cluster with senior service member 1In this case a distributed cache service called DefaultDistributedCacheService has started up on Member 1 of the cluster (the first JVM). As it’s the first service with this name to start it becomes the senior member – which means it has a couple of extra responsibilities, like sending out heartbeats etc.
- Once the cache services have been started Coherence will try and match the cache name that has been passed, in this case “trade-cache”, with the appropriate cache scheme (and service) that will manage this cache. It uses the cache scheme mappings part of the cache configuration file to do this and wild card matching (if necessary) to identify the right cache scheme.
Note: Regular expression parsing is not used and wild cards cannot be used at the start of the cache name.
- Once the correct cache scheme has been matched a reference to an existing cache managed by the cache service for this scheme will be returned or a new cache created, using the parameters of the cache scheme.
And in JConsole you can see the scope prefix being used in conjunction with service names – circled in red.