BEA WebLogic 8.1 implements the Java Management Extensions (JMX) 1.0. Most WebLogic subsystems (JMS Providers, the JDBC Container, ExecuteQueues, etc.) and their constituents are instrumented as MBeans and contain attributes by which they can be configured, monitored, and managed. An administrative server instance implements an MBeanServer through which its configuration and runtime MBeans and those of its managed servers may be accessed. A managed server instance implements an MBeanServer through which only the configuration and runtime beans that are resident on it may be accessed.

In a debugging scenario in which a running server is misbehaving, both its configuration beans can be examined to diagnose the problem. BEA Weblogic MBeans may be accessed programmatically via the Java API. In addition, WebLogic provides two mechanisms for accessing MBeans without programming: the weblogic.Admin command and the wlconfig ant task. There are, as well, numerous third-party tools that provide convenient access to MBeans. Two, which I will use in what follows, are wlsh, developed by Paco Gomez of BEA, and wlsScripting, developed using JPython by Satya Ghattu, also of BEA.

I have TestDomain configured with one cluster of two managed servers and an additional independent managed server. Connecting to the admin server with wlsh produces the result in Listing 1.

Connecting to ManagedOne produces Listing 2.

Now I can retrieve the ExecuteThreadCurrentIdleCount from the admin server with

wlsh TestDomain:/> idleCount=/ExecuteQueueRuntime/weblogic.kernel.Default/
ExecuteThreadCurrentIdleCount
variable idleCount set to /ExecuteQueueRuntime/weblogic.kernel.Default/
ExecuteThreadCurrentIdleCount (java.lang.String)
wlsh TestDomain:/> get $idleCount
15

It is almost always important in a production scenario for a crashed server to be restarted immediately. Listing 3, using wlsScripting, periodically checks the server’s status and restarts it if necessary. At the same time, it samples critical attributes for debug purposes.

Listing 4 shows the output of running the script against an instance of the examplesServer as a thread becomes stuck.

In a production environment where large amounts of debug are a problem, it is often difficult to track down transient errors. The JMX API can be used to report debug only in certain conditions. Listing 5 installs a counter monitor that is triggered when the OpenSocketsCurrentCount attribute of the ServerRuntime MBeans reaches a certain level. It doesn’t do anything in the NotificationListener.handleNotification method currently, other than note that a notification was received; however, in a real scenario you might launch a thread at this point that would report periodically on the values of attributes associated with critical resources, say the PendingRequestsCurrentCount from the ExecuteQueueRuntimeMBean for the default queue.

This is the output of running the DebugMonitor:

Java debug.DebugMonitor

Active Domain: medrecTwo
Active Servers:
        Name: MedRecServer
        ListenAddress: JWEAVER1/10.62.3.106
        ListenPort: 7001

        Number of servers active in the domain: 1
>>> MyCounter got notification: javax.management.monitor.MonitorNotification
...

Links