Tải bản đầy đủ - 0trang
Figure 1-10. UML diagram showing the implementation of the pattern in the form of the application
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
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