JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Published October 2007

Introduction

Ensuring a Java EE application is solidly constructed requires considerable skill. Ensuring it performs optimally is an even tougher task. So wouldn't it be nice it we could have our Java EE applications checked automatically - if performance and reliability limiting issues could be detected and explained for us? This is the objective of eoSense: to check applications are built correctly by applying Java EE framework knowledge systematically to automate the detection of many common problems, whilst simultaneously explaining server operation in a graphical, highly intuitive way.

eoSense is a runtime analysis tool. It operates by monitoring the execution of a Java application server and creating a dynamic abstract model of its operation. In-built model checking automatically detects performance and reliability problems and eoSense presents the zoomable model graphically to allow server construction to be verified or easily understood. eoSense can be used to ensure new projects are correctly constructed, or to explain the structure of legacy applications to anyone with a stake in maintaining them.

By modelling server operation eoSense is able to dynamically track service and resource usage, ensuring that applications have been or are being well constructed. Here are a few examples that illustrate the very interesting error detection capabilities this gives the tool:

• data usage is automatically tracked in the application to ensure that all the data available is required, i.e. it all gets used. Examples of areas in which data usage is tracke are JDBC access, JMS message payloads, and Http Session attributes
• inefficient creation of resources such as unneeded JMS connections or JNDI initial contexts is detected
• resource handling is verified, for example checking that JDBC connections are being correctly closed
• inefficient use of resources, such as JNDI contexts being used to fetch the same data repeatedly
• inefficient transaction grouping
• unreliable and difficult to maintain sequences of inter-component communication

Details of the technique used by eoSense to model and analyse server operation, Derived Model Analysis, have been published in JDJand Dev2Dev.

eoSense for WebLogic is available to download as a 15 day evaluation: for WebLogic or WebSphere click here.

Table Of Contents

Getting Started is Easy Automated Problem Detection Problem Alert: JDBC Connection not closed Problem Alert: Unnecessary Column Reads Problem Alert: Poison Message Conclusion

Getting Started is Easy

eoSense is designed explicitly to minimise the amount of user configuration input:

• When eoSense is started for the first time it asks for a WebLogic or WebSphere root directory. It uses this to automatically extract application and server information and to optionally install the eoLogic demonstration example.
• Getting eoSense running with an existing application is very simple. You point it at an existing start script and eoSense automatically makes a copy of your script and adds the required changes to launch its agent; it literally takes a few seconds to do this.

To show this in detail we will walk through the process of getting eoSense working with a WebLogic application. (While the example shown is a WebLogic application, getting started with eoSense for WebSphere is just as straightforward.) We start by pressing the green "Start" button as shown in Figure 1.

Figure 1

This button brings up the "Start Configurations" dialogue used to launch an application. See Figure 2.

The "Start Configurations" dialogue supports multiple stored configurations, each on its own tab. It comes configured to run the eoLogic demonstration example, and starting other applications is straightforward. Pressing "New Start Configuration" lets you browse to a WebLogic start-up script and a custom configuration is then created automatically based on that script!

Figure 2

Having created a configuration, press "OK" to start the application and watch as the dynamic model of the server is populated in the Server View as the server starts up.

Figure 3 shows eoSense attached to an application server running the eoLogic demonstration example:

Figure 3

The Server View in the centre of the tool provides a dynamic architectural diagram of the application. The diagram updates as the server runs. Architectural components are shown as items in the view and relationships between them shown as connecting lines. The view is zoom-able; in Figure 3 the zooming has been set to show the entire diagram of components and their relationships.

Figure 4 shows a portion of the detail available in the Server View when zoomed in. This screenshot shows a Servlet that has just posted to 2 JMS queues. In one case the post was via a transacted session that has not yet committed so the message is shown inside the producer. In the other the message was sent via a non-transacted session and has been placed on the (off-screen) JMS Queue.

Figure 4

The Server View is a dynamic representation of the current state of the application, but analysing in detail how the server operates requires the ability to review activity. The Server History View offers a powerful mechanism for reviewing the operation of the server, allowing the Server View representation to be replayed backwards or forwards so that server state and state changes can be viewed at any point in the past.

The Alert Log can also be seen in Figure 3. It displays problems that have been automatically detected and explains them in terms of the Server View diagram. In the next section we will explore some common problems found by eoSense.

Automated Problem Detection

eoSense automates the detection of a comprehensive range of performance and reliability problems mostly related to construction practices. The aim of the tool is to find these problems as early as possible in the development cycle.

Alerts are grouped into the category of the J2EE service they apply to. The categories supported are:

• JDBC
• SessionBean
• MessageDrivenBean
• Servlet
• JNDI
• JMS
• EntityBean
• JTA

Figure 5 shows Alert browsing by category in the Server Services View.

Figure 5

Figure 6 shows the properties and controls provided for the "Unnecessary column reads" Alert.

Figure 6

Problem Alert: JDBC Connection not closed

It is important that JDBC connections are closed correctly because they are a finite resource. eoSense tracks their creation and usage, and is able to pinpoint exactly at which point in the code the connection should be closed. Figure 7 shows eoSense's Alert Log when an unclosed JDBC connection has been detected.

The Alert describes the problem and suggests the solution. The unclosed connection is identified as an "Affected Entity" of the Alert. JDBC connections are modelled by eoSense and displayed as components in the Server View. Any Affected Entity in an Alert can be selected and examined in a number of other Views in the tool.

In this case the key to solving the problem is the "detectionStack" in the Alert. The stack identifies the end of the last method in which the JDBC connection has been used. It is at this point the connection should be closed. The blue frames in the stack indicate stack positions for which eoSense knows the source path. Double clicking on a frame will open a source editor at that point in the code.

Figure 7

To solve the problem we need to edit the method dsAccess() in JDBCSampleAccess.java and close the connection in its finally block. Figure 8 shows the editor View for the dsAccess() method at the top of the alerts detection stack; this is the method in which the JDBC connection must be closed.

Figure 8

Problem Alert: Unnecessary Column Reads

Pulling more data than you need from a database connection is clearly inefficient. eoSense detects when this happens by tracking what happens to the data returned by JDBC statements. Figure 9 shows the Alert Logwhen an "Unnecessary Column Read" Alert is detected.

Figure 9

The Items for this Alert list the columns in the ResultSet that have been pulled out of the database but not read. The stack in the alert is the point at which the ResultSet has been closed without all of the columns being read.

As with the previous Alert the blue stack frames are source positions that can be accessed by double clicking. Figure 10 shows the source code for the stack frame doAccessNames.java:68.

Figure 10

Not accessing all of the data in ResultSet "rs1" has triggered the Alert when the ResultSet is closed. Looking further up the function we see the set was created by the SQL query "select * for emp", yet only the columns "EMPNO" and "ENAME" are being used. The problem can be quickly resolved by changing the query to "select EMPNO,ENAME from emp".

It is important to note that eoSense did not detect this problem by detecting the SQL statement contained "select *". Such a trivial check would produce many false positive alerts and miss a great deal of inefficient data access.

Problem Alert: Poison Message

A "poison" JMS message is one that is repeatedly redelivered in a transacted session. It is caused either by a system exception being thrown from the business logic that processes the message or by a transaction rollback.

Figure 11 shows the Alert Log when a "poison" message is detected. To understand what caused this problem, we can cross reference from the Alert Log to either the Server History View or to the Active Events View.

Figure 11

Cross-referencing to the Server History View allows us to understand the server state at the time of the Alert. Figure 12 shows the Server History View at this point. We have zoomed in to show the problem detail. (When we cross-reference to either the Server View or the Server History View the components from which we cross-referenced are automatically selected; this means that as we use the zoom controls, they will automatically centre the view on the components we are interested in.)

Figure 12

We can see in Figure 12 that we have a JMS message 0x6b4 in the JMS Destination 0xea. Using the tabs on the message we can examine its payload- for the message in question the payload is "Invoice 1568 badbadbad Total 199200.99". In many cases it might be clear from examining the message payload what the problem is. However we can examine the problem in more detail by cross-referencing from the alert to the Active Events View.

The Active Events View is a list of events that drive the modelling and tracing capabilities of eoSense. It details every event that occurs in the eoSense data model. By default, events are sorted in chronological order, with later events at the bottom of the view. For this problem we can use the View to see what happened just before our "Poison JMS Message" Alert happened. Figure 13 shows the Active Events View with the Alert at the bottom of the screen.

Figure 13

Looking back though the Active Events View for the cause of the poison message (we are looking for an exception or a transaction roll back) we can see where a Message Driven Bean starts to process message 0x6b4. During this processing, the Active Events View records a runtime exception called "New Bad Item", and we can look at the stack for that exception to find where it was created. We can quickly cross-reference from the top stack frame to the source code for the onMessage() method of the MDB, which is responsible for throwing the exception. Figure 14 show the source displayed by eoSense for this frame.

Figure 14

Conclusion

eoSense goes beyond the capabilities of traditional debuggers, performance analysers or application monitors. It uses extensive inbuilt knowledge of the Java EE framework to interpret and summarise server operation, giving developers and testers a powerful ability to quickly find, diagnose and fix complex problems. The architects, developers and testers of Java EE applications need to be aware of the range of bad practices and construction problems that can derail their projects. But being aware of the problems doesn't always imply they will be avoided, and current validation methods all too frequently miss serious performance and reliability issues. eoSense represents a new form of runtime checking able to explain and analyse complex sequences of server operation in a highly intuitive way.

More information on eoSense can be found at on the eoLogic website.