Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

An Introduction to WebSphere Application Server Performance Tuning Toolkit

Part2: Analyzing Problem Scenarios

Shishir Narain (, IT Architect, IBM
Shishir Narain photo
Shishir Narain is Open Group certified Master IT Specialist with mature skills in IBM middleware products. He works in IBM Lab Services for WebSphere at India Software Labs, Gurgaon. He has 12 years of experience developing solutions for multiple clients. He has a Master of Technology degree from Indian Institute of Technology, Kanpur.
(An IBM developerWorks Contributing Author)
Tao Zhang (, Software Engineer, IBM
author photo
Zhang Tao (Jordan) joined IBM in 2009. He works in IBM China Software Development Lab WebSphere Application Server SVT team in Beijing. He is interested in WebSphere Migration, Intelligent Management, and high availability.
Wang Yu (, Software Engineer, IBM
author photo
Wang Yu (Edward) is a software engineer at the IBM China Software Development Lab in Beijing. He is a member of WebSphere Application Server SVT team. He is also interested in WebSphere Application Server performance analysis, performance tuning, problem diagnosis, and high availability.

Summary:  WebSphere® Application Server is a key component of enterprise architecture, and performance bottlenecks can affect multiple applications. This tutorial series introduces WebSphere Application Server Performance Tuning Toolkit, which can be used for uncovering performance bottlenecks and tuning the WebSphere Application Server infrastructure. This part presents several more problem scenarios and shows how PTT can help in detecting and resolving the issues.

Date:  24 Oct 2012
Level:  Intermediate PDF:  A4 and Letter (1646 KB | 21 pages)Get Adobe® Reader®

Activity:  9957 views

Connection leak problems

Connection leaks happen when the application acquires a connection from the connection pool and never closes it.

Triggering the problem

Listing 3 shows the code changes in the TradeAppServlet required to trigger a connection leak problem:

Listing 3: Code for triggering a connection leak
//For Connection Consuming
 		ConnectionConsumer cc = new ConnectionConsumer();

 class ConnectionConsumer extends Thread{
 public void run() {
 javax.naming.InitialContext ctx = new javax.naming.InitialContext();
 javax.sql.DataSource ds = (javax.sql.DataSource) ctx.lookup("jdbc/TradeDataSource");
 java.sql.Connection con = ds.getConnection();
 }catch(Exception e){

In the Server tab of Daytrader home page (see Figure 10), select the Jdbc Connection Leak checkbox and click Update Configuration. The application then leaks the connection of TradeDataSource at the specified frequency.

Figure 10: Specifying a JDBC connection leak on the DayTrader configuration screen
DayTrader                         configuration screen

Monitoring and investigating the problem

When the connection leak problem occurs, you see JDBC-related alerts in the dashboard (Figure 11).

Figure 11: PTT dashboard with alerts
dashboard                         showing alerts

Click the Open Monitor Page button on the overview screen, and you can notice several connection pool alerts in the alert section.

In order to get the JDBC connection allocation stack trace, you must enable the ConnLeakLogic trace. Select Enable Trace from the context menu, as shown in Figure 12.

Figure 12: Enabling trace on the server
menus for                         enabling trace

In the dialog box, select the Connection Leak trace and click OK to enable the trace (see Figure 13).

Figure 13: Enabling connection leak tracing
screen                         for enabling trace

Within a few minutes, the data source has quite a few leaked connections. You can observe them by choosing Show Connection Pool Contents (see Figure 14).

Figure 14: Showing connection pool contents
menu to display connection pool contents

In the connection pool content window (Figure 15), select TradeDataSource to check status of all connections, including the allocation time, used time, used thread number and allocation stack trace. Note that the allocation stack is displayed only for the connections that were made after you enabled the trace.

Figure 15: Connection pool monitor
screen showing connection pool details

From the connection pool content information, you can see that many connections are in use for more than 50 seconds, but not all of them can be found in the thread dump. This implies that the threads no longer exist but the connections have not been released. We can also notice that nearly all of the leaked connections were allocated with the stack trace below.

[8/7/12 20:39:59:437 EDT] 00000039 ConnLeakLogic 3   MCWrapper id 639d639d  
    Managed connection WSRdbManagedConnectionImpl@1cf81cf8  
    State:STATE_ACTIVE_INUSE Thread Id: 0000007e 
    Thread Name: Thread-86 Handle count 1 in-use for 181219ms
 at org.apache.geronimo.samples.daytrader.web.

This trace information clearly points out the problem code.

4 of 8 | Previous | Next


TutorialTitle=An Introduction to WebSphere Application Server Performance Tuning Toolkit