WebLogic Server (WLS) 7.0

Configuring Persistent WebLogic Server Processes
HP NonStop Server Platform Guide for WebLogic Server—525779-001
3-3
Managed Servers
where a shell process is being started. In a typical installation, this requires changing
scripts in the WebLogic Server home directory, too, or using the files from a different
location.
To cause the Java process to reuse the shell’s PID, at some point before the Java
process is started run:
export DEBUG_PROG=”exec”
By using exec exclusively when starting the intervening processes, it is possible to
have the OSH process effectively waiting on the WebLogic Server. A drawback to
using exec this way is that no shell post-processing can be done. For example, a
script cannot start the Java process, wait for it to terminate, and then perform cleanup
processing.
Whether or not exec is used, because OSH is the process being monitored by the
generic process mechanism, any script invoked by the generic process must avoid the
operations listed below:
•
The WebLogic Server process must run in the same CPU where the OSH process
was started. Otherwise, if the CPU where the OSH process is running fails, the
process will restart even though the original WebLogic Server process is still
running.
•
The shell script must wait for the WebLogic Server process. If it does not, the script
will terminate causing OSH to terminate and the generic process will restart.
•
The scripts should avoid calling “sleep” for any significant period of time unless you
modify the AUTORESTART parameter of the generic process to reflect the delay.
For example, if a script were to delay so that a failed start attempt of the generic
process takes two minutes, the generic process will continually restart the generic
process.
By using an AUTORESTART of 10, only ten failures in 10 minutes will cause the
generic process to move to the STOPPED state. By using a two-minute delay, the
process will never fail ten times in 10 minutes.
Managed Servers
Instead of using the WebLogic Server node manager, you can use the generic process
mechanism to monitor managed servers. Before using this approach, consider.
•
CPU load balancing may be slightly harder to achieve than when you use the
supplied nodemanager.sh. Each managed server must be configured to run in
more than one CPU to be fault tolerant and to allow in-doubt transactions to be
recovered after a server failure. To provide balance across CPUs, managed
servers have to be assigned to a subset of CPUs. Therefore, use the FIRSTOF
attribute with a list of CPU numbers.
•
The following node manager features are not available: