Intrexx Server monitoring with Java
Management Extensions (JMX)
In this month’s workshop, we would like to introduce you the so called ‘JConsole’. Its Java Management Extensions (JMX) provide the ability to monitor and administer applications programmed in Java. The different jobs are performed by MBeans. This tool will make a real difference to administrators who want to enhance the efficiency with which they supervise and maintain the Intrexx server.
Due to security reasons JMX is disabled for your Intrexx portal by default. Hence the Intrexx portal needs to be configured first in order to use the JMX console:
Firstly create a backup copy of the “portal.wcf” in <xtreme>\org\portalname\internal\cfg. Then open the file with a UTF-8 compatible editor and search for the section “Java Additional Parameters“. Check for the number of the last parameter entry. At the bottom of the “portal.wcf” you will find some commented lines, also being “Java Additional Parameters“. Remove the comments of those lines and enter a free port for communication between JConsole and the Intrexx server. Make sure that the numbering of “Java Additional Parameters“ is continued correctly in those three lines.
Example:
# Java Additional Parameters
#wrapper.java.additional.1=
wrapper.java.additional.1=-Dde.uplanet.jdbc.dump=true
wrapper.java.additional.2=-Djavax.net.ssl.trustStore=internal/cfg/cacerts
wrapper.java.additional.3=-Djava.io.tmpdir=internal/tmp
wrapper.java.additional.4=-Dfile.encoding=UTF-8
wrapper.java.additional.5=-Dlog4j.configuration=file:internal/cfg/log4j.properties
wrapper.java.additional.6=-Djava.security.auth.login.config=file:internal/cfg/LucyAuth.cfg
wrapper.java.additional.7=-server
…
…
…
# To enable JMX, uncomment these lines, replace <port number> and
# make sure that the N+x placeholders are set to unique values.
wrapper.java.additional.8=-Dcom.sun.management.jmxremote.port=9001
wrapper.java.additional.9=-Dcom.sun.management.jmxremote.authenticate=false
wrapper.java.additional.10=-Dcom.sun.management.jmxremote.ssl=false
wrapper.working.dir=c:\xtreme\org\myportal
The JConsole is ready to go after a portal service restart. To launch it, run “jconsole.bat“ (Linux: jconsole.sh) from <xtreme>\bin\windows (Linux: opt/xtreme/bin/linux). Logon with servername:port. Username and password are not required for this connection. The connection should therefore not be configured permanently because theoretically it would be possible for anybody who knows server IP and port to create a jmx connection. But for development and diagnostic purposes it is acceptable to use this unsecure connection. If the JConsole is not longer needed, put the comments back in place and restart the portal service once again.
Once logged in, a new window will popup. This monitoring screen contains several tabs. On the first tab you will see some graphs displaying e.g. CPU usage and amount of current live-threads. Since the graphs are updated every second, a precise monitoring of the resource utilisation is possible.
The other tabs Memory, Threads, Classes and VM-Summary provide according information which can be helpful to detect a problem and interrelationships.
The last tab is the MBeans tab. MBeans provide the possibility to perform different operations on the java machine. In addition to the default JMX MBeans, United Planet provides further MBeans which can be helpful for portal error diagnostics. They are located under de.uplanet.lucy.server.management.
Overview
Memory
This page contains information about the portal server’s memory usage. You might know this also from the performance monitor of the portal manager, but the values displayed in the JConsole are more precise. With automatic garbage collections the java machine makes sure to always set free enough memory for the portal to run smooth – resulting in a zigzag curve. You can also perform manual garbage collections (GC) to set free additional memory. The different charts contain information about committed heap memory, max. heap memory, garbage collection details etc.
Threads
This page provides information e.g. about the WebConnectorWorkerThreads. The analysis of those threads can be helpful in cases the portal is not accessible via the web browser even though there is no web server (IIS / Tomcat) malfunction. Ideally the WebConnectorWorkerThread state is on “waiting” – what means that it is ready to answer web browser requests. The graph displays the current amount of live threads as well as the highest amount of threads since the last portal service start.
Classes
Number of currently loaded classes, total number of loaded and unloaded classes.VM Summary
General information about the portal server such as uptime, loaded java classes, memory consumption, live threads etc.
MBeans
Mentioning the lot of MBeans would go beyond the scope of this workshop, hence only some specific logging MBeans from United Planet are illustrated below.
de.uplanet.lucy.server.management - Logging
| Attribute | Type | Description |
|---|---|---|
| JdbcTrace | Boolean | If true, all database queries will be logged in the portal.log. With that information it is possible to determine the speed of database queries which can be useful if you want to examine performance issues. |
| JdbcDumpOnClose | Boolean | If true, portal.log will log information such as the origin of not closed database connections. |
| ThrowExceptionOn-DeprecatedCall | Boolean | If true, an error message will be logged if a deprecated method was called. |
| BpeeDumpContext | Boolean | If true, Bpee context variables and their values will be logged. |
| Operation | Description |
|---|---|
| logSeparator / logString | Puts a separator (horizontal rule) or a string in the portal.log, which improves the clarity to the log file. |
| logThreadStacks | Puts the stack traces of the WebConnectorWorkerThreads in the portal.log. This can be useful in order to determine the reason why the portal is not accessible via a web browser. |
de.uplanet.lucy.server.management - WebConnector
| Attribute | Type | Description |
|---|---|---|
| Timeout | Long | Timeout of web-connector (in ms). Default value is 10 minutes. |
| Running | Boolean | Boolean Is the web connector running? |
| WorkerThreadCount | Int | Number of available worker threads. |
| AliveWorkerThreadCount | Int | How many worker threads are currently available? |
| WatchdogInterval | Long | Monitors thread activity. If the timeout has been reached, the worker thread will be recycled. |
| RequestCount | Int | Number of open requests. |
| BusyCount | Int | Number of currently performed tasks. |
| LogRequestProcessingTime | Boolean | If true, the duration of browser requests execution is logged in the portal.log. This can also be helpful when examining performance issues. |
| Operation | Description |
|---|---|
| startConnector | Starts the web connector |
| stopConnector | Terminates the web Connector |
