Using reference traces for troubleshooting WebSphere problems
JohnPape 0600007J6A Visits (3735)
Sometimes, during the course of testing or troubleshooting, we need to really understand what is going on in the depths of the WebSphere code when our enterprise application executes it's logic. When the basic log output from the server does not provide enough data to surmise what the root cause of the problem is we must then collect verbose tracing data from the server in hopes to capture the sequence of events that are occurring (or not occurring) while the application is running. This is where reference traces can become priceless.
What are they?
Reference traces are, simply put, application server traces taken in a controlled manner, usually in a test or development environment (such as Eclipse). The purpose of the traces is to capture the events of a "good" request/state in order to compare the data with traces taken during a "bad" or problem state. When combined with application logging, the trace data can yield great insight into the inner mechanisms of the server and the application running on it. Let's take an example.
Example Scenario: transaction problems with a database
Consider a situation where we need to understand exactly what is happening inside the application server during a database call from an enterprise application. In order to capture the trace data we need we would use a trace specification such as this:
This string would produce tracing centered around the Java™ 2 Connectors architecture, the Relational Resource Adapter, and WebSphere database and transaction management code. Exactly what we'd like to see. Now, couple that with some good logging practices in the application that we are going to run and we should be able to get the data we need.
For our test application we'll have a simple servlet that drives a JDBC call into a Derby database instance. Let's examine our servlet's code.
Here we have the init() method of the servlet. Nothing fancy here, just a bunch of initialization stuff with some java.util.logging usage. Notice that the init() method calls a method named getConnection(). This method is responsible for constructing a DataSource object for later use in the application. Below is the code for the getConnection() method and the lookupDataSource() method it calls.
The key thing to note here is that there are plenty of log entries created by the application during key parts of the work it does. This will provide reference points inside our WebSphere traces because we will be able to see all the events that occur inside WebSphere in between our application's log outputs.
All that's left to be done now is deploy the application on the server and start the server up (with tracing enabled). Once the server is ready, manipulate the application so that it performs the desired operations (a database call in this case). Then, stop the server, collect the trace data and take a look at it.
By searching through the trace for your application's log entries, you can begin to understand the sequence of events that are unfolding inside the server. Using this data, perhaps now you can really get to the root cause of the problem!!
Let me know how this works for you in the comments or connect with me on Twitter ⇒(@jpapejr)