WLWatchman Manual :: Technical Details

JMX works with the concept of a "managed object" or service; each such managed component has an associated MBean (or more than one) which allows some subset of CRUD operations. Each JMX container has an MBeanServer object through which the MBeans can be accessed. BEA extended the definition of MBeanServer in JMX1.0 to allow it to be queried remotely. Each MBean has a specific ObjectName that allows it to be discovered from an MBeanServer; this name is made up from a collection of name-value pairs. All MBean names contain Name, Location, Type and most of them have additional "key properties" as well. The ObjectName can be expressed as a colon separated list of name value pairs. For example, for a web application deployed inside an enterprise application, you need Name (see below for more details), Location (the target server), Type (WebAppComponentRuntime) but also ServerRuntime (the server name) and ApplicationRuntime (see below). This all gives you an ObjectName of (line broken for clarity):

Name=portalServer_portalServer_portalApp_defaultWebApp:
Location=portalServer:
Type=WebAppComponentRuntime:
ServerRuntime=portalServer:
ApplicationRuntime=portalServer_portalApp
		

Note that the Name and ApplicationRuntime take the internal deployment name, rather than the application name. So defaultWebApp - a web app deployed inside a portal EAR on, eg, portalServer is called portalServer_portalServer_portalApp_defaultWebApp not just defaultWebApp and the EAR is called portalServer_portalApp.

In addition, all MBean ObjectNames within WebLogic Server contain a domain property which is, unsurprisingly, the WebLogic domain.

The WebLogic MBean classes in weblogic.management.* provide type-safe wrappers to MBeans but during WLWatchman development we found them to be unreliable when accessed remotely and had to learn to love vanilla JMX.

Note: WLS9.0 uses a later version of the JMX specification.
Some of the above - specifically the MBeanHome and connecting to the server - does not apply in WLS9.0.
WLWatchman 1.3 and earlier do not work against WLS9.0.

The first thing to note is that WLWatchman is multi-threaded when running in monitoring mode; it spawns one thread for each WebLogic Server instance it's monitoring. This has the advantage that if one server is being slow or has died or been shut down, WLWatchman won't block waiting for results to come back from that server. The second thing to note is that it only connects to the admin server for a domain when fetching the full list of MBeans for the domain, or if you're monitoring it as well.

Rather than keeping a list of MBeans and MBeanAttributes directly, WLWatchman uses wrapper classes (which aren't really wrapper classes at all, but substitutes), ObjectWrapper and AttributeWrapper, respectively. The former knows the details of the MBean (key properties etc) and holds a reference to a list of AttributeWrappers which do a similar job for MBeanAttributes.

To get the full list of MBeans for a domain, WLWatchman first contacts the admin server for the domain and gets the full list of ServerMBeans. Each of these in turn is queried for its full list of MBeans, the list being filtered to include only RuntimeMBeans, using the specified includes/excludes lists, if present. Note that this filtering is done on the client side. Each RuntimeMBean is then queried in turn for it's full list of MBeanAttributes. A DOM tree is built up from the list of MBeans and MBean Attributes and this is written out to file, along with the server and WLWatchman runtime configuration. Details of the configuration file can be found here. The relationships amongst the wrapper classes for MBeans and MBeanAttributes are shown in Figure 4., below.

When monitoring a WebLogic Domain, WLWatchman starts one Thread for each server being monitored; each WLWatchmanThread holds a reference to the ServerConfig object for the server it is monitoring, from which it can obtain the list of relevant ObjectWrappers. (Note that it is possible to have multiple WLWatchmanThreads monitoring the same WLS server instance by configuring multiple target-server stanzas against the same server, though there's not real point in doing this.) It also holds a reference to the RuntimeConfig which holds both the refresh period (how long to wait between polls) and the repeat count (how many times to poll).

The WLWatchmanThread sleeps between polls and retrieves the data indirectly, by telling each ObjectWrapper to update itself. The ObjectWrapper invokes update on each of its AttributeWrappers which use the owning thread's MBeanServer instance to connect to the WLS instance and retrieve the new attribute value, triggering any alerts that may have been configured around the new value. Once this has completed for an ObjectWrapper, the thread invokes each of the Formatters in turn for the current ObjectWrapper before doing the same steps for the next one. Once all ObjectWrappers are processed, the thread sleeps.

Some degree of fault-tolerance is built in; if a configured WLS instance is not up when WLWatchman starts monitoring - or if it becomes unreachable during a monitoring run - WLWatchman will retry as many times as the polling is set to repeat. So if WLWatchman is configured to poll for data 15 times against a WLS instance that is unreachable, WLWatchman will instead try to connect 15 times, pausing for as long between tries as the configured polling interval. In actuality, you will see a longer pause as the only way WLWatchman knows the server is unreachale is when the connection to the server times out. This invariably takes longer than the polling request for updated data.

The two main areas where WLWatchman can be usefully extended are in the areas of Alerts and Formatters. These are covered on this page; the class diagrams for the OOTB packages are given here below.

The two diagrams below show inheritance and aggregation relations between the non-GUI classes (ie those that are used in both console and command-line modes) and the classes that make up the GUI.