Tải bản đầy đủ - 0 (trang)
Figure 1-10. UML diagram showing the implementation of the pattern in the form of the application

Figure 1-10. UML diagram showing the implementation of the pattern in the form of the application

Tải bản đầy đủ - 0trang

Basic is the base class for all of the classes that make up the implementation (with the

exception of WorkUnit, which represents the unit of work that is exchanged between

Supplier and Consumer). Controller is a class that acts as the JMX agent and is

responsible for creating the producer and consumer threads that run inside the application.

Queue is a thread-safe queue that acts as the monitor. Producer threads place items in the

queue in a thread-safe way, and consumer threads remove them. Worker is the base class

for Supplier and Consumer, because much of their behavior is common.

In the sample application, the following resources can be managed:





I encourage you to look at the source code to see exactly what attributes and operations

are on each of the management interfaces for these resources.

1.3.2 Source Code

The source code for the application is standalone with respect to each type of

instrumentation approach. There are three versions of the application, each in its own

package. The name of the package corresponds to the instrumentation approach. For

example, with the exception of common classes such as GenericException, the

application source code for standard MBeans is entirely contained in the standard

package; thus, if you install the source code to c:\jmxbook, the path to the application

source code for standard MBeans will be c:\jmxbook\sample\standard. All of the source

code shares the contents of the exception package. Other than that, however, the

application can be built and run independently of the other packages.

For each type of MBean, there is a Windows batch file and a Unix (Korn shell) script that

builds and runs the code for that instrumentation strategy. The name of the script or batch

file matches the instrumentation strategy: for example, the build script for dynamic

MBeans is called dynamic.sh, and the batch file for building the source code for the

version of the application instrumented as dynamic MBeans is called dynamic.bat. The


major differences between the application versions are in the source code. The console

output and the management view will show very little difference (other than output from

the Ant build script) between the versions of the application.

1.3.3 Building and Running the Application

Before you can build and run the sample application (see Section P.5 in the Preface for

details on how to obtain the application's source code), you must download the JMX RI

and Jakarta Ant. For this book, I used JMX RI 1.0.1 and Ant 1.4. You can obtain the

JMX RI at http://java.sun.com/products/JavaManagement/ and Jakarta Ant at


The name of the build file Ant uses to build the application for all of the instrumentation

strategies is build.xml. The build scripts are designed to work with very little

modification on your part. However, you may have to modify either the build script or

the Ant build file, depending on where you installed the JDK, the JMX RI, and Ant itself.

Example 1-5 shows an excerpt from build.xml.

Example 1-5. Selected portions of the Ant build file for the application, build.xml








As you can see, the Ant build file is an XML document. This is what sets Ant apart from

other build utilities, such as make. Each component to be built using Ant is called a target.

A target may have one or more dependent targets that must be built first, each of which

may be dependent on other targets, and so on. Ant resolves these dependencies for you. A

target is specified in an Ant build file as an XML tag called target and has the following


in which case mytarget depends on targets d1 and d2, or:

if mytarget has no dependent targets. Let's look at the build-standard target from

Example 1-5:


You can see that the build-standard target depends on the build-exception target.

Ant knows that there may be other dependencies, so it looks at build-exception:

and notices that build-exception depends on init. Ant then looks at init:

Ant sees that init has no dependencies, so it begins the build. init is built first,

followed by build-exception and finally build-standard. Notice the javac tag

within build-standard and build-exception. This is known as an Ant task. A task is

a Java class that executes within the JVM in which Ant is running (unless you tell Ant to

fork a new process when executing the task). The javac task is the java compiler. The

classpath, src, and include tags nested within the javac task tell the Java compiler

what the CLASSPATH is, the root location of the .java files, and the packages (directories)

to compile, respectively.

The application classes for each chapter in this book are built and run using either a batch

file or a shell script. If you are running the application on Windows (as I did to produce

the screen shots for this chapter), use the batch file (i.e., the .bat file). If you are running

the application on Unix, use the shell script (i.e., the .sh file). Throughout the rest of this

chapter, the examples will be Windows-based. There are two reasons for this. First,

because of the popularity of Windows, it is likely that most developers will be running

this operating system. Second, the differences in the behavior of the application when it is

run on Windows versus Unix are negligible.

To build and run the application, type in the name of the batch file you want to run, based

on the type of MBean instrumentation strategy you want to see in action. You will notice

that there is no detectable difference between what you see when you run the build/run

batch file and what you see in your browser (discussed in the next section), regardless of


the instrumentation strategy. Suppose we want to run the standard MBean batch file,

which will build and run the application as standard MBeans. Example 1-6 shows the

batch file that builds the application.

Example 1-6. standard.bat, the batch file that builds the application as standard MBeans









@echo Starting Build ...

call %ANT_HOME%\bin\ant %TARGET_NAME%

if NOT "%ERRORLEVEL%"=="0" goto DONE

%JAVA_HOME%\bin\java sample.standard.Controller 100 150


This batch file is very simple. Aside from setting a few environment variables, it does

only two things: it builds the application by calling Ant, and, if that succeeds, it starts the

application. Figure 1-11 shows the output of running the batch file. Recall our earlier

discussion of how Ant resolves target dependencies; you'll see that the targets are built in

the order described there.

Figure 1-11. Running the build/run batch file for standard MBeans

All of the batch files (standard.bat, dynamic.bat, and model.bat) operate as described

below, but I've used standard.bat here for the purposes of illustration.

In each version of the application, Controller contains the main() method that starts the

producer and consumer threads and is itself an MBean that can be managed and

monitored. There are two command-line arguments to Controller's main() method: the

work factor for the producer thread and the work factor for the consumer thread. Notice

that in standard.bat values of 100 and 150, respectively, are specified for these arguments.


I set these values for a reason: it is unlikely that you will find an application of the valueadded producer/consumer pattern where the producer and consumer perform an equal

amount of work. These command-line parameters to Controller allow you to simulate

this asymmetry. When Controller is started, one producer thread and one consumer

thread are created. However, Controller has a management method that allows you to

start additional threads to balance out the workload (we will see how to do this later).

Figure 1-10 illustrates the relationship between the various classes in the application,

where there is a single Queue object into which Supplier threads place WorkUnit objects

and from which Consumer threads remove them. For a single unit of work, here is the

flow of control:

1. The Supplier performs an amount of work N—where N is specified on the

command line to Controller—and places a single WorkUnit object into the


2. The Consumer removes a single WorkUnit object from the Queue and performs an

amount of work M—again, where M is specified on the command line to


These steps are repeated for each work unit.

The work that is performed by Supplier and Consumer threads is to

calculate prime numbers. The amount of work specified on the

command line to Controller is the number of prime numbers to

calculate for each WorkUnit. The Supplier calculates N primes,

then places a WorkUnit object into the Queue. The Consumer

removes a WorkUnit object from the Queue and then calculates M


This section looked at how to run the sample application and briefly discussed what it is

doing internally to simulate the production and consumption of units of work. I strongly

encourage you to examine the source code for yourself to see the various attributes and

operations available on the management interfaces of each resource in the application.

In the next section, we will look at how to use a web browser to monitor and manage the

sample application's MBeans.

1.3.4 Monitoring and Managing the Application

Once the application is running, you can point your web browser to port 8090 (the

default—you can change this, but if you do so, remember to point your browser to the

new port number). Figure 1-12 shows the result of pointing my web browser (which

happens to be Internet Explorer) to port 8090 after running standard.bat.

Figure 1-12. The management view of the application in Internet Explorer


Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Figure 1-10. UML diagram showing the implementation of the pattern in the form of the application

Tải bản đầy đủ ngay(0 tr)