Thanks Phil for the reply. I've changed maxWait to 1000 and
removeAbandonedTimeout to 300. MySQL wait_timeout is set to 500.
I've put some System.out.printlns in and can see that this page is
taking less than 1 second to process, even in the cases where I get the
DBCP object created 2010-11-10 12:54:14 by the following code was never
closed:
java.lang.Exception errors. So I don't think the timeout is being hit.
I can also see that the finally block is being executed, I'm now
printing to catalina.out after each object is closed.
Note that this isn't being reported everytime the page loads, just once
in a while.
Are there cases where this exception is generated even though the
connections were successfully closed? Or is there a way to get more
info from AbandonedTrace.java?
Thanks,
Tyson
On 11/10/2010 2:44 AM, Phil Steitz wrote:
On 11/8/10 7:19 PM, Tyson Lowery wrote:
I have a JSP page that is getting reported for not closing
connections in catalina.out. I'm running Tomcat 6.0.26, so I believe
we are on DBCP 1.2. I've racked my brain trying to figure out how
these connections could possible remain unclosed. Does anyone have
any tips or suggestions on how I can further troubleshoot this?
If your page holds onto a connection for longer than 55 seconds or
there are queries taking longer than 55 seconds to execute, DBCP will
consider the associated connection abandoned. Try increasing this
setting. Note also that maxWait is specified in milliseconds, so
below is a pretty low setting.
Phil
Here's the latest version of our connection pool settings:
<Resource name="jdbc/myDB" auth="Container" type="javax.sql.DataSource"
maxActive="350" maxIdle="40" minIdle="10" maxWait="45"
removeAbandoned="true"
removeAbandonedTimeout="55"
validationQuery="select 1"
testWhileIdle="true"
testOnBorrow="true"
logAbandoned="true"
timeBetweenEvictionRunsMillis="100000"
minEvictableIdleTimeMillis="400000"
numTestsPerEvictionRun="3"
username="user" password="password"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://1.2.3.4/myDB?autoReconnect=true&jdbcCompliantTruncation=false"/>
The JSP page literally has everything enclosed in a try block and
all connections closed in a finally statement. See below:
Connection con = null;
Statement stmt = null;
ResultSet rset = null;
String query = "";
Statement stmt2 = null;
ResultSet rset3 = null;
try {
// page executes
}
catch (SQLException ex) {
out.println ("\n*** SQLException caught ***\n");
while (ex != null) {
out.println ("SQLState: " + ex.getSQLState ());
out.println ("Message: " + ex.getMessage ());
out.println ("Vendor: " + ex.getErrorCode ());
ex = ex.getNextException ();
out.println ("");
}
}
catch (java.lang.Exception ex) { // Got some other type of
exception. Dump it.
ex.printStackTrace ();
}
finally {
if(rset != null) {
try {rset.close();}
catch(Exception e) {
System.out.println("Exception in finally rset");
e.printStackTrace();
}
rset = null;
}
if(rset3 != null) {
try {rset3.close();}
catch(Exception e) {
System.out.println("Exception in finally rset3");
e.printStackTrace();
}
rset3 = null;
}
if(stmt != null) {
try {stmt.close();}
catch(Exception e) {
System.out.println("Exception in finally stmt");
e.printStackTrace();
}
stmt = null;
}
if(stmt2 != null) {
try {stmt2.close();}
catch(Exception e) {
System.out.println("Exception in finally stmt2");
e.printStackTrace();
}
stmt2 = null;
}
if(con != null) {
try {con.close();}
catch(Exception e) {
System.out.println("Exception in finally con");
e.printStackTrace();
}
con = null;
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]