Anatomy of the application server JVM in WebSphere Application Server
Vikram Thommandru 1200007CN8 Visits (29704)
Sometimes servers do not start. Maybe it is due to a bad build, the configuration has gotten corrupted, or it just stopped working. This blog helps you understand the anatomy of the Application Server start up process. It provides you with troubleshooting and debugging techniques to determine why the server is not starting or why the server is not stopping.
Starting the server
Let's see what happens when a server is started using the startServer.sh /bat server1 command.
Two Java virtual machines (JVM) are actually launched. The first JVM is the systems management server launch utility. Its job is to locate the appropriate configuration, for example the server.xml file, and spawn the second JVM, which is the actual server process.
Spawning is achieved by constructing a command, such as java -Dxxx -classpath x;y;z etc, and executing it. This server launching process waits until it receives a status back from the server process unless you specify the -nowait parameter.
However, starting in WebSphere Application Server V8.0, there is a little change in the design of server start up process. When an application server starts for the first time after installing an update -- that is, a fix pack or an interim fix -- the server launch application performs any post-install configuration by invoking the runC
Here is an example output from this launch process:
ADMU0116I: Tool information is being logged in file D:We
Stopping the server
The server is stopped using the <PRO
As a result, a new JVM is created to read the configuration and send a message to the server to shut down. By default, the stopServer utility does not return control to the command line until the server completely shuts down. Unless the command is invoked with the “-nowait” option, it will not return until the server is fully stopped. A user ID and password is required to stop a secure application server.
Application Server start up fails but only the startServer.log file is created
Possible causes of the problem:
Things to check when Java is corrupted
Try running the “java –fullversion” command from the WAS_
Check the nati
Invalid JVM arguments are set on the application server JVM
When the java class cache is corrupted
It is possible that the Java cache is corrupted. A class cache is an area of shared memory of a fixed size that persists beyond the lifetime of any JVM that is using it. A JVM does not own the cache and there is no master and slave JVM concept; instead, any number of JVMs can read and write to the cache concurrently. A cache is deleted either when it is explicitly destroyed using a JVM utility or when the operating system restarts. A cache cannot persist beyond an operating system restart. Its purpose is to reduce the virtual memory footprint and improve JVM start up time. By default, this option is enabled starting with SDK 1.5 on all IBM platforms.
Run the WAS_
You can disable Java class cache feature permanently using the -Xshareclasses:none argument. To delete it, complete these steps in the administrative console:
When the OSGi cache is corrupted
The Equinox OSGi framework is used to manage class loading and relationships between the server component bundles. In some cases, the cached bundle data, which is maintained on a per profile basis and has a separate cache at the WAS_HOME level for installation-wide processes, can become out-of-sync with the actual binaries on the server. You can use the osgiCfgInit.sh(bat) script to clear and recreate the OSGi cache.
You should run the osgiCfgInit script on the command line from the WAS_HOME/bin or user
Avoid trouble: Before you run the osgiCfgInit script, stop the server on which the script will be run. If you run this script on a server that is active, the server might have problems trying to read or update the cache after the script is finished.
There might be cases after applying a fix or fix pack with the Update Installer or with IBM Installation Manager, that servers (deployment manager, node agent, and application servers) might fail to start. The SystemOut.log file will not be generated to indicate a reason. The startServer.log shows:
!MESSAGE Error reading configuration: /hom
It is necessary that you run the osgiCfgInit.sh(bat) script before you start any server JVM for the first time after you install a fix pack when similar errors are thrown. The following documents describe some known issues with the OSGI cache in the context of root user and non-root user managing the WebSphere Application Server file systems:
This error gets thrown when the JVM cannot find the appropriate native library that is required for WebSphere Application Server to start.
Startup issues and a SystemOut.log file is generated
You can ignore the following issues:
Server stops by itself (graceful shutdown)
When you set the -Dco
For platforms where an IBM Software Development Kit is used, a Javacore is generated in the working directory of the application server. For all other platforms, a thread dump is written to the native_stdout.log file for the application server. Solaris/HP thread thread dumps are written out to the native_stdout.log as well as verbosegc. In addition to the thread dump, the stack trace of the current thread that is processing the shut down is included in the SystemErr.log for the application server.
This information should help to determine the source of the problem that is causing the Application Server to shut down gracefully .
I hope this blog helps you in understanding the anatomy of the WebSphere Application Server start up process and provides you with some troubleshooting / debugging tips for all currently supported releases.