New parameter in nodemanager.properties

While creating a presentation about the startup sequence of WebLogic server I noticed a new parameter in the nodemanager.properties of a 10.3.4 domain:

DomainsDirRemoteSharingEnabled=false

This parameter was mentioned to me in a SR just recently as hidden feature, though the SR is about a 10.3.3 nodemanager in combination with a shared filesystem for the domain. Since the parameter didn’t solve the issue I didn’t blog about it *yet*. AFAIK no documentation exists about this parameter today, so I can only guess the exact working. I *think* (hope!) it is a parameter to instruct the nodemanager to do some more extensive checking on a managed server than just bluntly starting a managed server based on the contents of $DOMAIN_HOME/servers/$SERVER_NAME/data/nodemanager directory .

More to come later.

**UPDATE**
A very friendly Advance Resolution Engineer gave me this description of the parameter:

Introduced a Nodemanager property called DomainsDirRemoteSharingEnabled. When this property is enabled, the Node Manager adds NMHostName property to the servers startup.properties file while starting the server. While recovering the server, the Node Manager compares the NMHostName property in the startup.properties file with the hostname on which it is currently running and if it matches then only NM will recover the server.

Usefull utility for end of the road SR’s

I just recieved a usefull utility from Simon for end of the road SR’s

You can guess my state of mind now 🙂

WLS, nodemanager and startup.properties

It’s been a while since I blogged, been way to busy working on a couple of production systems. Anyway, while running an SR with Oracle about the nodemanager and some crash recovery issues  (a blog post will follow as soon as a solution is found) I ran into yet another documentation “feature”.

The Fusion Middleware documentation contains lots of “practices” (I wouldn’t call them best 🙂 ) which have little to do with the technical functioning of the product and everything to do with personel preferences (i.e. “it worked for me”). Some engineer setting up a fusion middleware environment for some customer and promoting his personal notes to be best practices is not the type of “Best Practice” or manual I would like to see from Oracle. A population of one (1) is not a valid sample for a “Best Practice”.

As an example, this part of documentation says:

Step 7: Define the Administration Server Address Make sure that a listen address is defined for each Administration Server that will connect to the Node Manager process. If the listen address for an Administration Server is not defined, when Node Manager starts a Managed Server it will direct the Managed Server to contact localhost for its configuration information.

I think this is incorrect because the nodemanager checks a file when it starts up a managed server. This file can be found at $DOMAIN_HOME/servers/$SERVER_NAME/data/nodemanager/startup.properties. An example of this file from one of my testservers is:

#Server startup properties
#Sat Feb 05 10:41:39 CET 2011
Arguments=-Djava.net.preferIPv4Stack\=true -Dsb.transports.mq.IgnoreReplyToQM\=true -Xmanagement\:ssl\=false,authenticate\=false,port\=7091 -Djavax.management.builder.initial\=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder -Djava.security.egd\=file\:/dev/./urandom -Djava.security.jps.config\=/u01/app/oracle/user_projects/domains/base_domain/config/fmwconfig/jps-config.xml -Xms5g -Xmx5g -XXtlaSize\:min\=2k,preferred\=512k -XXcompaction\:percentage\=20
SSLArguments=-Dweblogic.security.SSL.ignoreHostnameVerification\=true -Dweblogic.ReverseDNSAllowed\=false
RestartMax=2
RestartDelaySeconds=0
RestartInterval=3600
AdminURL=http\://192.168.6.1\:7001
AutoRestart=true
AutoKillIfFailed=false

It contains the AdminURL (192.168.6.1 resolves to the AdminServer of my test setup). This property file is setup upon first startup of the managed server. When you boot the managed server this leads to the following startup parameter for the jvm (found in the .out file of the managed server):
-Dweblogic.management.server=http://192.168.6.1:7001

So I don’t agree that the managed server checks localhost if the AdminServer has no listen-address. I think that line in de docs should be corrected as a documentation error (at best it’s incomplete)

When you learn more about the startup.properties, you also know that the statement that you should always need to use the startWebLogic.sh script to start the AdminServer after domain creation is false. Yes you get an error when you start the AdminServer from the nodemanager if it’s the first time you boot this AdminServer, but if you manually create the startup.properties file and optionally the boot.properties (if you run in production mode) you can start the AdminServer from WLST (which helps when you script your deployments).

hope this helps.