Java Magazine - November/December 2011

each run. This approach is not perfect, though, because both the stress test and the load generator must be started and stopped manually.

A continuous integration (CI) tool, such as Hudson or Jenkins, is capable of automating the whole lifecycle and can easily deploy STM and start the load generator automatically.

Hudson and Jenkins support a periodic build execution (for example, with a single configuration tag: @midnight). With Hudson or Jenkins, setting up a nightly executed stress test only takes minutes. You have to deploy the STM application first and launch the stress test generator afterward. For a GlassFish Server Open Source Edition deployment, this requires just a single line:

asadmin deploy --force […]/ StressTestMonitor.war.

JMeter can also be started without the GUI in headless mode. It requires another line: jmeter -n -t predictions .jmx -l predictions.jtl. The parameter -n prevents the GUI from appearing, the parameter -t specifies the configuration file (created with JMeter in GUI mode), and -l specifies the log file, which can be analyzed with JMeter after the test.

A Hudson or Jenkins “Free Style Software Project” build with two build steps

and Execute Stress Tests. You don’t have to create a shell script or a batch file. The commands can be executed directly by Hudson or Jenkins.

VisualVM can still be used to monitor the application in real time or identify the hot spots. All the relevant monitoring data is persisted in a database table and can be analyzed easily after the test.

@Inject Event<Snapshot> escalationSink;

@Schedule(minute="*",second="*/5",hour="*")
public void gatherAndPersist(){
Snapshot current = dataProvider.fetchData();
em.persist(current);

if( current.isSuspicious()) escalationSink.fire(current);

}

COMMUNITY JAVA IN ACTION

Nice-to-Haves

The solution described so far is good
enough for getting started. The inter-
esting parameters, such as JVM and
application server monitoring data, are
gathered and persisted automatically
during a nightly job. Because of JSR-77
(the management and monitoring
API), all application servers
also provide access to the
statistics of all deployed
Java EE components.
Application-specific EJB
beans (usually the facade
to your business logic) can
be monitored using exactly
the same mechanism.

You will get the number of concurrent requests, the current number of active instances (and, thus, the number of concurrent transactions accessing the bean), and business method runtime statistics, such as slowest and average execution times.

For example, PredictionAudit EJB bean

See all listings as text

pool data is accessible under http:// localhost:4848/monitoring/domain/ server/applications/com.abien_ TestingEJBAndCDI.war_ 1.0-SNAPSHOT/ PredictionAudit/bean-pool.

All the monitoring data is stored in a single table, which makes the data available to tools such as JasperReports or Eclipse BIRT. Charts and reports are only a few clicks away. The Snapshot entity is exposed through JSON, which makes it “consumable” by all JavaScript and JavaFX applications as well.

Furthermore, the Snapshot entity is a Java class and can contain additional validation or processing logic. It is trivial to escalate “suspicious” Snapshot instances with CDI events, as shown in Listing 9.

A suspicious Snapshot listener will only have to implement a method with an annotated parameter to receive the event public void onSuspiciousEvent(@ Observes Snapshot snapshot){}.

All suspicious events can be analyzed
in real time, sent using e-mail, or just
aggregated and exposed with JMX.

Stress-test-driven
development is
the right choice for
Java EE. Instead of
applying optimizations
prematurely, you
should concentrate
on implementing
pure business
logic and verifying
the expected behavior
with automated tests
and hard numbers.

Conclusion: No Excuses

Java EE 6 applications are always executed concurrently. Even with unrealistic stress tests, you will learn a lot about system behavior and identify some bottlenecks or concurrency bugs.

The earlier and more frequently stress tests are executed, the more you will learn about the application’s runtime behavior. Application server configuration problems, potential bottlenecks, synchronization bugs, and memory leaks can also be identified during stress tests. </article>