Java Node Manager Enhancement to Implement Start/stop Scripts For Coherence Nodes (Doc ID 1461666.1)

Symptoms

This is specifically when there is a requirement to add java options to the classpath of each cache server.  This can normally be done through the Administration console by setting the Server Start options for that Coherence node - these entered via the admin screen are correctly passed to the node on startup. However this option is impractical in a production situation because of the large number of nodes that could be in the cluster.

According to the documentation, when starting WLS nodes it is possible for the node manager to execute a script before start and after shutdown of the node using the startScriptEnabled parameter.  Unfortunately this doesn't work for Coherence servers; the Node Manager doesn't use a script, and instead starts the node using the Coherence jar using the parameters supplied via the WLS Admin Server screen.  If the Node Manager did use a script, then the script could be used to set the classpath and JVM parameters, and that script could be distributed with the application jars and therefore decouple administration from build and deploy functions. 

There can also be a case where it would be desirable to be able to invoke a custom class to perform initialization tasks, for example Spring application context initialization. However, the Node Manager has hard-wired the class that it invokes to start a Coherence node, weblogic.nodemanager.server.provider.WeblogicCacheServer, presumably that class has the wherewithal to talk to Node Manager for shutdown, status requests etc.  Therefore it is not possible to extend this and replace the class with an alternative custom startup class.

Additionally, using deployable shared libraries won't solve the purpose because the actual requirement is to completely decouple administration from the build and deploy functions especially when te environment may have around 50-60 Coherence clusters and growing. A standardized approach to cluster management to optimize the support and maintenance costs is required.

So without a fix for this cluster management via WLS is not practical.

A real time use case can be summarized as following:

1. It involves WLS admin server in the deployment phase - one of the objectives we are trying to achieve here is to separate release and deployment from management. Use WLS only for starting and stopping nodes and clusters - not as part of the release process.   
2. Even if we used an approach like this to manage the classpath issue, we still have the JVM arguments problem. The need to manage JVM arguments via WLS is not a practical proposition for a production environment.

Having the ability for Node Manager to call a script to set classpath and  JVM arguments would be a simple, elegant, and a complete solution. 

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.