Basic start-up troubleshooting JAVA – the logical sequel!
After writing Basic start-up troubleshooting – the logical sequence! I promised to deliver a Java version of it. It has taken rather a long time but I finally put together my attempt to describe the basic flow of a Java System startup and the possible areas where problems can occur.
This is not by any means perfect but I like to believe it gives a decent overview of the process.
As on ABAP the first step is to check and start the database. No dedicated developer trace is created in the work directory as the database has its own logs. If the database does not start correctly it should be visible within seconds and errors will be available within the DB logs.
Developer traces: Refer to your DB logs.
JSTART is called next, it takes the role of the Java instance controller which analyzes its configuration and initializes SAP signal handling and opens the control port.
There is very rarely an issue with the initial load of JSTART. If for some reason this fails you most likely have a problem with your instance profile.
Developer traces: dev_jstart
The Java instance controller reads the instance definition and creates a child process that initializes JVM and starts the OFFLINE DEPLOYMENT program which performs the deployment steps in the Java database.
In the ‘business as usual’ scenario this is very unlikely to end up in an error. These days most deployments are done automaticaly using SUM, the traces will be filled when the instance is stopped and started during the SUM deployment phase.
Developer traces: dev_deployment, std_deployment.out and jvm_deployment.out
BOOTSTRAP synchronizes the binary data in the Java database with the local file system.
This is where you will most likely find issues during your system startup. Errors during this phase are common and usually caused by issues in one of the following areas;
1. Problems at DB Level
There is a large number of reasons for this to fail going from DB availability to problems with listeners and DB user authentication.
2. Problems at the File System Level
Problems with environmental variables, file permissions, file availability, mounts, etc…
3. Problems at the Configuration Level
Java VM settings configured incorrectly, usually related to memory allocation.
Developer traces:dev_bootstrap, std_bootstrap.out and jvm_bootstrap.out
Internet Communication Manager (ICM)
The Java instance controller starts the processes for infrastructure nodes – the most important in my opinion is ICM; ICM handles the HTTP request directed to the AS JAVA system.
If there is an issue with ICM you’ll see an error on screen while calling the java standard URL. http://<host>.<fqdn>:<port> you will also find the details on the ICM developer trace.
Developer traces: dev_icm
When all infrastructure processes are started, the Java instance controller starts the processes for the server nodes.
Finally, your Java system is running and if there was an issue with any request dealt with by this server node you will find information about it on the developer trace.
Developer traces: dev_server0, std_server0.out and jvm_server0.out
Hope this is a good basic explanation of where to start when troubleshooting a Java Startup problem!
As a reference I have taken the freedom to borrow this lovely chart from SAP Help to ilustrate my case
Love to hear your comments,