Warning Deploying Coherence in a production environment is very different from using Coherence in a development environment. Development environments do not reflect the challenges of a production environment. |
Coherence tends to be so simple to use in development that developers do not take the necessary planning steps and precautions when moving an application using Coherence into production. This article is intended to accomplish the following:
Deployment recommendations are available for:
During development, a Coherence-enabled application on a developer's local machine can accidentally form a cluster with the application running on other developers' machines.
|
During development, clustered functionality is often not being tested.
|
What is the type and speed of the production network?
|
Will the production deployment use multicast?
|
Are your network devices configured optimally?
|
How will the cluster handle a sustained network outage?
|
See also:
During development, developers can form unrealistic performance expectations.
|
During development, developer productivity can be adversely affected by inadequate hardware resources, and certain types of quality can also be affected negatively.
|
What are the supported and suggested server hardware platforms for deploying Coherence on?
|
How many servers are optimal?
|
Does it matter how JVMs are distributed among servers?
|
See also:
During development, developers typically use a different operating system than the one that the application will be deployed to.
|
What are the supported and suggested server operating systems for deploying Coherence on?
|
Avoid using virtual memory (paging to disk).
|
See also:
During development, developers typically use the latest Sun JVM or a direct derivative such as the Mac OS X JVM.
|
Which JVM configuration options should be used?
|
What are the supported and suggested JVMs for deploying Coherence on?
|
Must all nodes run the same JVM vendor and version?
|
See also:
The minimum set of privileges required for Coherence to function are specified in the security.policy file which is included as part of the Coherence installation. This file can be found in coherence/lib/security/security.policy. If using the Java Security Manager these privileges must be granted in order for Coherence to function properly. |
Be cautious when using instrumented management and monitoring solutions.
|
During development, use the development mode.
|
Starting with Oracle Coherence 3.3, customer-specific license keys are no longer part of product deployment. Be sure to obtain enough licenses for the all the cluster members in the production environment. The servers hardware configuration (number or type of processor sockets, processor packages or CPU cores) may be verified using ProcessorInfo utility included with Coherence. java -cp tangosol.jar com.tangosol.license.ProcessorInfo If the result of the ProcessorInfo program differs from the licensed configuration, send the program's output and the actual configuration to the "support" email address at Oracle. |
How are the edition and mode configured?
|
The RTC nodes can connect to clusters using either Coherence TCMP or Coherence Extend. If the intention is to connect over Extend it is advisable to disable TCMP on that node to ensure that it only connects via Extend. TCMP may be disabled using the system propery tangosol.coherence.tcmp.enabled.
|
|
|
|
Unless explicitly specified all cluster nodes will be storage enabled, i.e. will act as cache servers. It is important to control which nodes in your production environment will be storage enabled and storage disabled. The tangosol.coherence.distributed.localstorage system property may be utilized to control this, setting it to either true or false. Generally only dedicated cache servers, all other cluster nodes should be configured as storage disabled. This is especially important for short lived processes which may join the cluster perform some work, and exit the cluster, having these nodes as storage disable will introduce unneeded repartitioning.
|