On 10/14/2012 12:14 PM, g. rgar wrote:
I am developing a small java ee app (java 1.7, eclipse juno, tomcat 7.0.30,
windows 7 professional, mysql-connector-java-5.1.22-bin.jar, vanilla
servlets/jsp MVC)
All works fine - while I change things and save .java files in eclipse it
apparently redeploys the app on Tomcat - after some redeployments I get :
com.mysql.jdbc.exceptions.
jdbc4.MySQLNonTransientConnectionException: Data source rejected
establishment of connection, message from server: "Too many connections"
WARNING: Unexpected exception resolving reference
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Data
source rejected establishment of connection, message from server: "Too
many connections"
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:407)
at com.mysql.jdbc.Util.getInstance(Util.java:382)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1013)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:982)
at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1116)
at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2338)
at
com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2371)
at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2163)
at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:794)
at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:47)
at sun.reflect.GeneratedConstructorAccessor22.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:407)
at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:378)
at
com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:305)
at
org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:278)
at
org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:182)
at
org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:699)
at
org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:631)
at
org.apache.tomcat.jdbc.pool.ConnectionPool.init(ConnectionPool.java:485)
at
org.apache.tomcat.jdbc.pool.ConnectionPool.<init>(ConnectionPool.java:143)
at
org.apache.tomcat.jdbc.pool.DataSourceProxy.pCreatePool(DataSourceProxy.java:116)
at
org.apache.tomcat.jdbc.pool.DataSourceProxy.createPool(DataSourceProxy.java:103)
at
org.apache.tomcat.jdbc.pool.DataSourceFactory.createDataSource(DataSourceFactory.java:539)
at
org.apache.tomcat.jdbc.pool.DataSourceFactory.getObjectInstance(DataSourceFactory.java:237)
at
org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:143)
at
javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
at org.apache.naming.NamingContext.lookup(NamingContext.java:843)
at org.apache.naming.NamingContext.lookup(NamingContext.java:154)
at org.apache.naming.NamingContext.lookup(NamingContext.java:831)
at org.apache.naming.NamingContext.lookup(NamingContext.java:168)
at
org.apache.catalina.core.NamingContextListener.addResource(NamingContextListener.java:1061)
at
org.apache.catalina.core.NamingContextListener.createNamingContext(NamingContextListener.java:671)
at
org.apache.catalina.core.NamingContextListener.lifecycleEvent(NamingContextListener.java:270)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5173)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.StandardContext.reload(StandardContext.java:3920)
at
org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:426)
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1345)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
at java.lang.Thread.run(Thread.java:722)
I suspect the data source is not closed properly **on redeployment** - I
have no probs while keeping the app open. I am able to replicate the
behavior by just touching the files and never once open the app in the
browser or do anything in my app (involving DB access)
context.xml :
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ted2012">
<Resource name="jdbc/TestDB" auth="Container"
type="javax.sql.DataSource"
maxActive="100" maxIdle="30" maxWait="10000" username="root"
password="root"
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3306/ted2012?useUnicode=yes&characterEncoding=UTF-8"
removeAbandoned="true" removeAbandonedTimeout="60" />
</Context>
</pre>
Pool class :
<pre>
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.sql.DataSource;
class DBConnectionPool {
private DataSource ds = null;
private DBConnectionPool() {
try {
Context context = new InitialContext();
Context envctx = (Context) context.lookup("java:comp/env");
ds = (DataSource) envctx.lookup("jdbc/TestDB");
} catch (Exception e) {
e.printStackTrace(); // TODO
}
}
private static enum PoolSingleton {
POOL_INSTANCE;
private static final DBConnectionPool singleton = new
DBConnectionPool();
private DBConnectionPool getSingleton() {
return singleton;
}
}
private static DBConnectionPool getDBConnectionPoolInstance() {
return PoolSingleton.POOL_INSTANCE.getSingleton();
}
static Connection getConnection() {
try {
return getDBConnectionPoolInstance().ds.getConnection();
} catch (SQLException e) {
e.printStackTrace(); // TODO
return null;
}
}
static void freeConnection(Connection c) {
try {
c.close();
} catch (SQLException e) {
e.printStackTrace(); // TODO
}
}
/**
* This is intended to be used in finally blocks and therefore MUST NOT
* THROW. See :
http://today.java.net/article/2006/04/04/exception-handling-
* antipatterns
*
* @param set
* @param statement
* @param conn
*/
static void closeResources(ResultSet set, Statement statement,
Connection conn) {
if (set != null) {
try {
set.close();
} catch (SQLException e) {
e.printStackTrace(); // TODO
}
}
if (statement != null) {
try {
statement.close();
} catch (SQLException e) {
e.printStackTrace(); // TODO
}
}
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
e.printStackTrace(); // TODO
}
}
}
}
</pre>
I do close connections/ results/ statement (using the closeResources - I
never get too many connections if I do not redeploy - let me know if it is
an eclipse problem
Please get back to me if you need any more logs/traces etc
My first reaction is that you're leaking connections, and that reloading
in Eclipse exacerbates this.
One thing that I notice in your code (haven't really studied it) is that
you have no finally block. This means that if you throw any exceptions,
all bets are off at to the state of that connection.
Since you're printing the stack trace, what do the log files show? It's
a bit of a pain to find if you're running under Eclipse - I think the
log files exist in:
workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp[n]\logs
where [n] is an internal server number that Eclipse keeps track of.
I wonder what happens when you unload your application and reload it on
a stand-alone version of Tomcat. Check to see if you have a ClassLoader
leak with the manager application and something like VisualVM.
Finally, here's a good template for creating and destroying database
connections:
http://blog.christopherschultz.net/index.php/2009/03/16/properly-handling-pooled-jdbc-connections/
I use a variation of the above code as my base class, then inherit all
of my other DAO classes from either the transaction version or the
non-transaction version. This makes writing JDBC code pretty mindless
since all of the boilerplate code has been taken care of by the base class.
. . . . just my two cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
