I wanted to check the current system properties and JVM flags of a Weblogic managed server, so I first used "
wlst" (Weblogic scripting tool) to access that managed server. It was a little time consuming task and you need to have a knowledge about the inside of Weblogic server. But later I found out about this
jinfo tool.
jinfo is a very useful tool for retrieving Java system properties and JVM flags (JVM command line flags) (and changing values of JVM flags) of a running local Java process or a remote server process. It was lot easier than accessing these properties using "
wlst" or "
jconsole". According to the
"jinfo" documentation, This tool can also be used to get system properties and JVM flags of a remote server process.
But I am going to focus only about how to get those details of a local Java process in a Linux environment.
You can get the process ID of the specific process by doing a command like below in Linux. (Please replace "managed1" with a word (main class name, for example) in the command used for starting the Java process.)
ps -ef | grep "managed1"
In the output of above command, you can get the PID of the relevant Java process.
Then execute the following command. Please replace <PID> with the actual PID of the process.(I am assuming that path to JDK bin folder is in PATH environment variable).
jinfo <PID>
It will attach to the process related to that PID and will show the Java system properties and JVM flags like below.
Attaching to process ID 25965, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 11.0-b17
Java System Properties:
java.vendor = Sun Microsystems Inc.
org.xml.sax.parser = weblogic.xml.jaxp.RegistryParser
sun.java.launcher = SUN_STANDARD
com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.woodstox = true
sun.management.compiler = HotSpot Tiered Compilers
os.name = Linux
sun.boot.class.path = /opt/jdk1.6.0_11/jre/lib/resources.jar:/opt/jdk1.6.0_11/jre/lib/rt.jar...
weblogic.threadpool.MinPoolSize = 50
java.vm.specification.vendor = Sun Microsystems Inc.
.....
VM Flags:
-Dweblogic.Name=managed1 ..................
......................
Other features of this tool:
(I didn't have a chance to experiment with these yet):
1. Get only JVM flags of the relevant Java process.
jinfo -flags <PID>
2. Get only Java system properties
jinfo -sysprops <PID>
3. Get a value of a specific JVM flag of the relevant Java process.
jinfo -flag <JVM_FLAG_NAME> <PID>
4. Change the value of a specific JVM flag of the relevant Java process.
a) Enabling a boolean JVM flag,
jinfo -flag +<JVM_FLAG_NAME> <PID>
b) Disabling a boolean JVM flag,
jinfo -flag -<JVM_FLAG_NAME> <PID>
c) Setting a value of a JVM flag
jinfo -flag <JVM_FLAG_NAME>=<NEW_VALUE> <PID>
If you get VMVersionMismatchException,
Sometimes you may get following VMVersionMismatchException.
Attaching to process ID 6461, please wait...
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.tools.jinfo.JInfo.runTool(JInfo.java:79)
at sun.tools.jinfo.JInfo.main(JInfo.java:53)
Caused by: sun.jvm.hotspot.runtime.VMVersionMismatchException: Supported versions are 17.1-b03. Target VM is 20.5-b03
at sun.jvm.hotspot.runtime.VM.checkVMVersion(VM.java:223)
at sun.jvm.hotspot.runtime.VM.<init>(VM.java:286)
at sun.jvm.hotspot.runtime.VM.initialize(VM.java:350)
at sun.jvm.hotspot.bugspot.BugSpotAgent.setupVM(BugSpotAgent.java:594)
at sun.jvm.hotspot.bugspot.BugSpotAgent.go(BugSpotAgent.java:494)
at sun.jvm.hotspot.bugspot.BugSpotAgent.attach(BugSpotAgent.java:332)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:163)
at sun.jvm.hotspot.tools.JInfo.main(JInfo.java:128)
... 6 more
The reason for this is, you are using a "
jinfo" tool related to a different java version than the JVM used to start this targeted process. If you get above exception, please find the JDK home of the JVM used for the targeted process, and use the "
jinfo" tool in the bin folder of that JDK home.
According to the
jinfo tool documentation, it seems this is not a standard tool of the JDK. In the documentation, there is a note saying
"NOTE - This utility is unsupported and may or may not be available in future versions of the JDK. In Windows Systems where dbgent.dll is not present, 'Debugging Tools for Windows' needs to be installed to have these tools working. Also the PATH environment variable should contain the location of jvm.dll used by the target process or the location from which the Crash Dump file was produced.
For example, set PATH=\jre\bin\client;%PATH%
"
