What’s JMX in the first place!

JMX (Java Management Extensions) technology provides a simple, standard way of managing resources such as applications, devices, and services. Because JMX technology is dynamic, you can use it to monitor and manage resources as they are created, installed and implemented. (Source: Sun Microsystems, “Ch1 : Introduction to JMX Technology”)

A simple illustration of how the JMX architecture can be found in Wiki, “Java Management Extensions”. This will give you an overview of the different levels and how the communication work between them.

Additional references can be found in Sun Microsystems which we recommend browsing through to get an general understanding of this technology.

• “Overview of Monitoring and Management”
• “Java Management Extensions (JMX) Technology”
• “JDK 6 Java Management Extensions (JMX)”

Ok, now we’ve got an understanding on JMX. In the context of WebLogic, JMX is in place to monitor the resources usage of the server.

How does WebLogic (JMX) monitoring work in LoadRunner?

JMX specification is designed to monitor Java applications from another Java application. Therefore, in order for LoadRunner to monitor WebLogic resources via JMX, it will be required that LoadRunner to be a Java-application to perform the monitoring and collect the data from the MBeans. This is achieved by installing JDK of the same version as the WebLogic server and running a mini version of application server in the LoadRunner machine to collect the monitoring data which is reason the installation of JDK as well as the copying of the weblogic.jar file is required.

What can you get from WebLogic (JMX) monitoring?

You will be able to monitor the runtime state of the WebLogic via JMX from the Runtime MBeans. The list of JMX counters can be found in “WebLogic Server MBean Reference”.

If you need to see how much time is spent or breakdown on individual methods, SQL calls or even the chain of calls, you are looking at the wrong tool. You may like to explore Diagnostics for a solution. Refer to “What’s Diagnostics?” for more information

We’ve put together a list of references that will you understand the JMX technology and also the fundamentals that WebLogic (JMX) working with LoadRunner. We hope this information is useful to you. If you have additional information with regards to the monitoring, please feel free to write in to us.

Parsing error.
Details: host localhost,port 1112, line: 1.
Reason: Invalid at the top level of the document.
.
Contents: java.lang.Exception:java.lang.SecurityException: [Security:090398]Invalid Subject: principals=[weblogoc.admin.mbean, Administrators] [MsgId:MMSG-47587]

Background information: I’m monitoring 4 WebLogic servers using WebLogic (JMX) Monitor in LoadRunner and adding their JMX stats into Controller. Upon adding the subsequent server, the error appeared after entering the username and password to the Controller. I’m using LoadRunner 9.0 and Weblogic 8.1 in this context.

The principle behind it is that the mini Web server launched by the Controller for monitoring WebLogic JMX listens on port 1112 by default (defined in {LoadRunner}\dat\monitors\weblogicmon.ini). This port is occupied and the mini Web server cannot be started according to Document ID 42701, Error: “Failed to connect to XML source on 1112″. This hinted me on the change of port. As suggested in the document, for every Weblogic server (JMX) that I’ve added, I change the port number on the file as below (Source: HP Openview Document ID 42701):

The solution is to configure the default port to a one not in use

1. Navigate to {LoadRunner}\dat\monitors.
2. Open weblogicmon.ini in Notepad.
3. Change

Weblogic=weblogic.jar
Port=1112

to:

Weblogic=weblogic.jar
Port=1114 {Or any other port that is free on the Controller machine}

4. Save the changes.
5. Close the “Add Measurement” dialogue and re-open it. You should be able to add the JMX measurements. Repeat from [1] to [5] in the event that when the error occured for subsequent WebLogic servers.

To do that, you have to download the utility, PsTools from Microsoft Sysinternals. PsTools has a command, PsList that can look at the thread level on the OS.

Pslist

Follow the instructions to install the utility.

1. Open command prompt, get the Process ID of the running application instance:

pslist processname -x

Where “Process Name” is usually java.exe. There should be more than one java.exe due to the application instance and the WebLogic instance. So you have to be sure of which console the application is on. The results returned should be the memory consumed and the amount of CPU utilization.

Pslist java

Pslist java -x

2. With returned results, look at the User Time (which represent the amount of application time consumed on the processor). Take note of the highest timing and the Thread ID also abbreviated as TID.

3. Go to the application instance console, perform a thread dump (Press “Crtl-Break”) and observe the dump. In JRockit JVM, you should be able to see a similar tid in decimals. While in Sun HotSpot JVM, it is called nid, in hexadecimal format which required you to perform conversion to decimal (use the scientific calculator to do it). (Prior to that, I would also redirect the console output to a log in the startup script.)

Thread Dump

4. Ok, now search for the Tid from Pslist in the thread dump. Recall the Tid that was output from pslist java -x, the values for Tid and tid are the same and nid in decimal format. Remember for Sun HotSpot, you need to convert the Tid from Pslist into hexadecimal to do the search. You should be able to find out the specified thread and drill down to the activity the thead is performing at that point of time. From there, it’s your call on the follow up actions such as reviewing the codes or examining the database for remedy.

Scientific Caculator