Introduction
If you write your MobiLink synchronization scripts using the MobiLink Java API, the MobiLink Server will use a Java VM, but it’s launched internally. It does not spawn a new java process, but instead will load the jvm library into it’s own memory space. When this happens, the MobiLink Server process can effectively be treated as a Java Runtime Environment with respect to the debugging tools that are available in the Java Development Kit.
In this blog, we’ll explore how to capture the java call stacks for all the threads executing inside the Java Runtime Environment running inside the MobiLink Server. This is something you might want to do if your MobiLink Server is hung and you wanted to check on the state of the threads in the MobiLink Server that are executing Java code.
Gathering the Stack Traces
This should be as simple as running the "jstack" tool from the Java SDK, but it's complicated slightly by the fact that the MobiLnk Server ships with a Java Runtime Environment, and not the Java SDK, and by the fact that the jstack tool from the Java SDK must be compatible with the Java VM that you are running.
Step One : Determine which Java Runtime Environment is being used by the MobiLink Server
When you install SQL Anywhere and the MobiLink Server, a Java Runtime Environment is also installed in the %SQLANY17%\bin64\jre180 directory. This is the Java Runtime Environment that will be used by default by the MobiLink Server, but you can over-ride the default Java Runtime Environment on the MobiLink start line. If the options inside the -sl java() switch on the MobiLink command line include a -jrepath, that is the Java Runtime Environment that is being loaded, not the Java VM in %SQLANY17%\bin64\jre180.
Step Two : Determine the version of the SAP Runtime Environment
Change directory into the location where the Java Runtime Environment is installed and open a file named "buildinfo.txt". If this file does not exist, then you are likely not using an SAP Java Runtime Environment, and the rest of this blog will not help you. You'll need to find the compatible Java Runtime Environment on the Oracle web site.
The last line of the buildinfo.txt file will be the "vmVersion" which will have a format similar to "vmVersion=8.1.004". This informs you that you are using SAP Java Runtime Environment 8.1, patch level 4.
Step Three : Download the full SAP Java Runtime Environment for your version
Browse to
https://launchpad.support.sap.com/#/notes/1442124, and scroll down the document until you find and then click on the link for the version of the SAP Java Runtime Environment you are using. Near the top of the downloads page that has just opened, ensure that you are looking at the SAP Java Runtime Environment for the correct platform, and then locate the download that matches the patch level you are using. For the example above, it's called "SAPJVM8_4-80000211.SAR".
Step Four : Unpack the SAR file you just downloaded
If you don't know what to do with a SAR file (I didn't), you'll need to download the SAPCAR utility for your platform from
https://launchpad.support.sap.com/#/notes/212876. Once you have both the SAR file and the SAPCAR utility downloaded, you can unpack the SAR file. DO NOT unpack the SAR file on top of your existing Java Runtime Environment, just unpack it into an empty directory somewhere. The SAPCAR utility is very tar-like in it's syntax. You can unpack the SAR file with the following command :
SAPCAR -xvf SAPJVM8_4-80000211.SAR
Step Five : Gather the call stacks
You're now ready to use the jstack utility that you just downloaded and unpacked. From where you unpacked the files, change directory into the sapjvm_8\bin directory, where the jstack utility exists. Find the process ID of the MobiLink Server and execute the following :
jstack -J-d64 [process_id] > ml_java_call_stacks.txt
Conclusion
Gathering the java stack traces from a hung MobiLink Server can be a very useful tool for technical support or development to determine the root cause of the problem. One would typically run the jstack utility against a java executable, but because the MobiLink Server spawns a Java Runtime Environment internally, the same process can be run against the MobiLink Server process.
